So put a big red scary "PRESS THIS BUTTON AND YOU'LL GET HACKED IN TEN MINUTES UNLESS YOUR COMPUTER DOES NOT CRASH BEFORE THAT" that turns telemetry off and let me press it.
Ever worked the help desk? My users would push that button twice then call me in 5 minutes to tell me their computer has been hacked (just after it crashed of course).
I hate the telematics and the "anti-user" stubbornness of Windows in general, but at the same time, I know all too well who they're targeting and why. More and more of my less technical users are requesting Macs, which are a PITA to admin but at the same time generate fewer tickets because they're really hard to fuck up. I don't like seeing Windows move this direction, but I get it.
This has worked reliably in ALSA before it has worked reliably in PulseAudio (and, in fact, way before PulseAudio received any meaningful adoption, when Fedora enrolled everyone in PA's beta testing).
Well, maybe in the later days, but there was a long time when it didn't work well at all. I remember having to mess with the ALSA configuration to make it work. And then you also had apps which only supported OSS and getting them to work together with ALSA was an additional pain.
The reason for that was that while dmix was available for a long time, it was not enabled automatically on hardware without hardware mixing. More recent versions will silently (heh) enable it on hardware thats known to not have hardware mixing.
What later days? Software mixing worked fine in ALSA in 2004-2005, and OSS emulation had been working reliably way before that. The first PulseAudio release was in 2004, and it wasn't adopted by Fedora until way, way later.
That's the thing -- it's (no longer) easy at all. When accessing every other function requires guessing which hamburger menu it's hidden behind, it looks clean and easy to use, but it's not.
In the meantime, a bunch of us developers are desperately trying to figure out what the fsck broke this time, drinking our sorrows about this new life where we can't debug anything that happens at boot, and frantically setting up BSDs on our laptops at home, so that we can at least get a break from this mess when we're at home.
I (thankfully only) used to do Linux BSPs in a former life. In the last year or so of doing that, I think we spent about 15-20% of a project's time debugging systemd problems and working around it being too smart for its own good. 20% for the bloody init system sounds fine until you realize the rest of the time included stuff like writing or expanding device drivers.
"I (thankfully only) used to do Linux BSPs in a former life. In the last year or so of doing that, I think we spent about 15-20% of a project's time debugging systemd problems and working around it being too smart for its own good."
It would be great to see in-depth experience reports for systemd, good and bad. The overwhelming majority of anti-systemd commentary has just been noise for so long, and as somebody who is very much in favor of systemd, I'd love to see some real discussion and actual informed criticism.
I avoid systemd like the plague, but have hit these bugs anyway:
They keep having embarrassing security exploits (like remote code execution in the dns reimplementation, or handing root to strange usernames by design).
Many people say they broke logging because the binary files create administrative nightmares and are flakey by design. Ubuntu LTS' systemd logging subsystem definitely broke a bunch of production machines I work with by stealing control from rsyslog during a botched update. We have a bunch of tooling for log processing and shipping. The systemd binary format is a usability nightmare compared to .gz files.
Being a member of the "video" group is no longer enough to use DRI or the new rootless X11 stuff. One of the crucial system calls has been hardcoded to only work when invoked by UID zero. The kernel maintainer rejected a one line patch to fix it. The argument is that systemd can launder the call through its own authentication subsystem, so the kernel doesn't need to implement workable permissions for /dev/ anymore. I have no idea how far that brain damage has spread. Just "chown root:root /dev/video; chmod og-rwx" if you want systemd! Don't proactively break every non-systemd distro out there by intentionally crippling the kernel API!
I've noticed that systemd debian-derived desktops age poorly -- uninstall a bunch of packages and reinstall, and you will find you can no longer log in correctly. I never managed to root cause it. It looked like init issues with multiple repros across multiple OS vendors.
The task that they are hiring for does not generate enough revenue to be worth at price X. The business may not stop from operating if these tasks are not done, or not done on a priority basis.
So... the business doesn't even generate enough revenue to afford hiring the kind of people who can keep it running well, or at least not as well as its owners would want it to be running?
No, you are free not to accept inadequate pay, just as the companies are free not to accept excessive pay. It's a marketplace, just think in terms of bids and asks.
It's a marketplace until the business starts using a nonexistent "shortage" to lobby government to add more visa slots and create programs to funnel more students into the jobs it wants to pay less for.
It's also a marketplace where one side has much more information and negotiating power than the other.
Of course you are free to do whatever you want, it's the entitlement that pisses me off. Somehow, employees charging "too much" is not ok and totally not the companies' fault, whereas offering too little is great management. Then they wonder why there are six million jobs that they can't fill.
If there are no takers, then the task should not be done, yes. What a lot if people seem to imply is that these jobs should not be advertised in the first place, which I disagree with.
Unless they people causing them waste incur costs greater then they benefits, it won't change. Hiring has gone digital, reducing costs, so of course garbage job postings have increased.
I always find this an interesting argument; while company foo has more power than a random job seeker, they certainly don't have more power than all the other companies seeking that employee. In order for companies to wield their supposed salary-depressing power there would have to be massive collusion. For an example of how (in)effective that is, look how much salaries increased while Apple Google et al were colluding.
I think this is more simple: units of production are less obviously attributable to FTE count or difference in skill in software than in other fields. Therefore, management is less sure how much developer they actually need to purchase.
Companies are certainly beholden to the market: one of the ways the power asymmetry is unfolding is in their successful manipulation of H1 visa legislation.
None of this is all-or-nothing. Companies use their power over the individual applicants as a response to the vagaries of the market. However, the basic logic divide and conquer ing means that they always have more power than individuals selling their services to them.
Except they won't/can't. And the parasites are actually working very hard.
They just get inordinately rewarded for their work, because most of their work involves maintaining the status quo, with them on top. It's their families that don't work.
Moreover, so far the only thing revolution has been good for is shuffling the parasites. I strongly suspect there are biological reasons behind our feudal support of strongmen.
My requirements were those that any OS X and iOS developer have, which don't require UNIX CLI rather XCode tooling, and are happy to use any UNIX certified POSIX system for the occasional CLI automation of OS X and iOS development.
Now those that bought OS X as a pretty alternative to GNU/Linux and *BSD, for development that should actually be done on those systems, might miss something like homebrew.
Interesting definitions. Theirs excludes you as an OSX developer, and yours excludes them as OSX developers. How about: Your requirements weren't those of "any OS X and iOS developer", unless you apply a "no true Scotsman" argument. Similarly, a nicer CLI environment is only applicable to some styles of dev on OSX.
Except for all the tooling that people like to use that isn't covered under Unix certification, of course. It's not like the Open Group is the ultimate arbiter of useful software on Unix-like systems.
iirc, they actually contacted Max Howell (creator of homebrew) and got his input on how to make command line tools work better for developers and homebrew specifically.
I think he left sometime last year
https://changelog.com/podcast/232 they start talking about his departure from Apple at 55 min and 26s, unless he went back recently
Yes. This is all handled via udev, udisks & co., XFCE, Gnome and KDE have nothing to do with it (other than having it work more or less out of the box).
udev existed before systemd, but was merged to it sometime in 2014. By quick Googling there are still several forks that maintain it as a separate component.
My understanding is it's in the same repository (for convenience), but is logically separate, so "forking" it mainly means copying the correct directory.
Eh, not really. Many Parabola users who use OpenRC instead of systemd still use systemd-udev, as opposed to eudev or one of the other non-system forks.
I don't know what they use, but there's always eudev, Gentoo's fork which works just fine, and offers pretty much everything that udev offers (except for the systemd dependency).
I personally don't think it's that much of a trouble to just journalctl for the /dev/sdX of the inserted device and then sudo mount /dev/sdX /mnt/tmp manually, because I so rarely plug USB drives. For permanently attached or frequently used devices you can add them to fstab and mount by UUID to a fixed path.
Either way, you will still always need to umount manually or risk loosing data.
Honestly -- I have no idea, I only had to do it a few times, on Yocto and buildroot images, and in pretty restricted cases. It was pretty easy (basically udev has this file which matches a set of device selection rules with a set of actions, effectively saying "if I encounter a device of this type, I'm going to do these particular things"), but I googled my way through it.
I expect there are some distro-specific hoops to jump through, but I have no idea which ones -- I really don't like automounting, I keep it disabled even on KDE.
