notalaser

After seeing the astroturfing in this thread, I'm switching to Vivaldi or Chromium, not Tor Browser.

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.

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.

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).

No, but they will affect most of the equipment connected to those generators.

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.

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.

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?

Should workers be doing charity work now?

> But maybe the job isn't economically worth it at the higher salary?

As in, their business doesn't even generate enough revenue to afford hiring the kind of people who can keep it running?

> But, I'm kinda baffled why anyone would volunteer to provide free labor to one of the largest and most profitable companies in the world.

YES! MacOS users don't need to document macOS as a volunteer project, they need to demand Apple to give them their money's worth.

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.

(Why? Old habits die hard, I guess?)

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).

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).

*nix, iSeries, cockroaches, and finally, that VAX that someone still has running somewhere.

But it's not "just" limited tools and a need to train developers. A language having a small community results in a lack of library and collaboration; you end up dealing with tool vendors who barely manage to keep themselves afloat, let alone invest in development, with long unmaintained libraries, with months, sometimes years passing between when a new architecture or OS is available and when the compiler and the libraries you use get updated.

It's not too different from how things are in Common Lisp land, a language (and a land...) that I'm pretty familiar with. It's a great, probably the best language. There are a few success stories, but truth is, in 2017, most large-scale, non-hobby projects are failures.

Do you think (as in bet-your-company's-profits-on-it believe) that Ada will still be a first-class language in GCC ten years from now (the standard product lifecycle for RHEL), and that you'll be able to staff the project and build a community throughout that period?

I love Ada, and I've written Ada code, but there are so few people who know it that building a community around an init system built in Ada is very difficult. The barrier of entry for contributions is "learn this language developed by the DoD thirty years ago that you won't use unless you work on embedded systems, in the US, for a living." I agree that it's a better technological choice than C, for any systems-level program, but Red Hat, like virtually any company out there, cares about money more than tech.

FreePascal, Oberon, ActiveOberon, are all great (I'm hesitant to say I know Oberon since I haven't written Oberon code in like 15 years), but besides having the same problem as Ada above, the communities maintaining the compilers are small and understandingly fragile. systemd is still going to be here 15 years from now. Oberon -- who knows?

Modula really belongs in a museum :-).

Besides, they'd all need things like D-Bus bindings etc., a working, stable compiler is just the first step.

> Someone would ask this sooner or later, so.. why is this written in C, really?

When systemd was started, Rust barely had a working compiler and go had been announced for about one year.

I ended up trying apulse myself last evening and it seems to work fine, so crisis averted for now. I don't particularly enjoy having stuff much with LD_PRELOAD and friends but I suppose it's less effort.

Thing is... I know what you're saying, and I don't doubt it's probably just some trivial issue that I can solve with a two-hour trip to Google and my PA config files. However, not running PA works fine, and has been working fine for like 12 years on every computer I've owned. It's literally no effort at all. I could spend some time getting sound to work again, or do absolutely nothing at all and have it working fine, just as it's worked for the last six years on the machine in question.

The days of endlessly troubleshooting ALSA settings and OSS wrappers aren't really gone if we're troubleshooting PA settings and ALSA wrappers instead.

Maybe this will help: https://github.com/i-rinat/apulse .

I just got bit by the new Firefox dependency. Installing PulseAudio left me without sound in VLC (even though I'm using the PulseAudio output plugin) and Firefox can't play videos anymore.

I haven't tried apulse -- I solved the problem by not using Firefox anymore -- but I hear it gives good results.

Good point -- that's one of the reasons why I think it's "just" a red flag. The one place that I mentioned what exactly like that -- small company, couldn't afford too much wage, hiring mostly students or fresh graduates, often based on recommendations. The structure of the team was largely a reflection of our own social networks and of the bias inherent in hiring third-year students. For almost an year, it was a six-man effort. There was only one woman in our team.

Full disclosure: white dude, not a minority of any kind in my country.

Five years ago, I would have said that the percentage of women in an office isn't necessarily a good indicator of anything. Nowadays, this would be my first advice: ask how many women work there.

With maybe one exception, all the places I've worked in that had very few women were terrible places to work in. Most of them were unpleasant to work in even for men who think "bro" is not a word to be uttered after you turn 19.

Teams that have a strong bias against women act on it almost universally: they drive candidates away with shitty and/or unenthusiastic interviews and they make life hard for those candidates who do get through. They don't end up with all-male teams just because reputation preceeds them and no woman wants to work there -- they end up with all-male teams because prejudice and insecurity tend to tip the balance of their hiring decisions, too.

It's not a universal predictor, but I definitely consider it a red flag. Frankly, it's one that I look at, too. I'm not the SJW type, but when I got into this whole programming thing, hacker communities used to be inclusive and diverse, and I kind of like to keep that going.

Because it's highly lucrative.

In my experience, while the statistics that the article quotes are obviously correct, the reasons have very little to do with the architecture, and they very much mimic the way that the "community" works. Linux' architecture has very little to do with why communication (and contributions) are the way they are. In fact, the architecture is largely designed precisely so that it can withstand the sort of organizational pressure that the Linux kernel faces. See, for example, the recent(-ish) rejection of AMD's drivers: they got rejected because they included a HAL, which -- based on previous exeperience -- is usually a bad idea in an open system, as it tends to depend on highly organization-specific knowledge, and the volume and difficulty of maintenance work makes it difficult to manage by a non-committed community once the main owner drops it for greener pa$ture$.

The very separation that the article draws "core" vs "drivers" is actually highly representative of how the Linux community is structured. Most of the core work (including the driver subsystem's backbone) is done by long-term contributors who actually work on the Linux kernel full time. Most drivers actually come from occasional contributors.

Driver contributions are "specialized" for the same reasons why they're specialized on pretty much any non-hobby operating system, namely:

1. The expertise required to write complex drivers mainly exists within the organization that sells the hardware. Needless to say, these people are largely paid -- by the hardware manufacturers! -- to pay drivers, not contribute to what the article calls core subsystems. There are exceptions ("trivial" devices, such as simple EEPROMs in drivers/misc, are written by people outside the organizations that sold them), but otherwise drivers are mostly one-organization shows. In fact, for some hardware devices, "generalists" don't even have access to the sort of documentation required to write the drivers in the first place. (sauce: wrote Linux drivers for devices that you and me can't get datasheets for. $manufacturer doesn't even bother to talk to you if you aren't Really Big (TM))

2. Furthermore, there really are subsystems in the kernel that are largely a one-company show and are very obvious examples of Conway's law. IIO drivers, for instance, while started by Jonathan Cameron who, IIRC, is really an independent developer, are largely Intel' and Analog Devices' -- to such a degree that, even though they follow the same coding conventions, if you've worked there enough, you can tell who wrote a given snippet. Same goes for most of the graphics drivers. Most of Infiniband used to be IBM, I think. If you dig down in the drivers subsystems, you'll see even funnier examples (my favourite example are ChipIdea USB controllers; a few years ago, support for USB slave mode on some Broadcom SoCs broke down because Freescale pretty much took over de facto ownership of the drivers, and some of their changesets worked fine on their ARM cores, but broke on Broadcom's funky MIPS-based cores)

Also, this is very weird to me:

> Adherence to Conway's Lay (sic!) is often mentioned as one of the benefits of microservices architecture.

Back in My Day (TM), adherence to Conway's Law was usually considered a negative trait, summarized by the mantra that, in the absence of proper technical leadership, an organization of N teams tasked with writing a compiler is going to produce an N-pass compiler.

Of course, this is a most negative example, but are we really, seriously considering that adherence to Conway's law is a positive thing today? That it's actually a good idea for the architecture of a software system to reflect the "architecture" of the team that created it, rather than, you know, the architecture that's actually best for what it's meant to do?

> Or because it makes maintaining a distro so much easier ?

In my experience, such a general statement is not true of any init system. I had to maintain a systemd-based system (albeit not a general-purpose one) and I was moderately happy. The profiling tools are great and units are easy to write even by people with no Linux development experience (hint: easy to outsource to cheap consultancy firms). On the other hand, it's extremely complex; if you get into trouble with systemd itself, you've got a lot of code reading to do. systemd upstream itself is a pretty volatile target, so you regularly end up with things that used to work three versions ago but now bork.

Maybe for a general-purpose distribution like Debian, or for a special-purpose, but server-/cloud-oriented distribution, it makes life easier, but at the other end of the spectrum I wouldn't say it made my life any easier than other init system (albeit not much harder, either).

AmiKit does something of a similar consequence (though with an opposite approach) via Rabbit Hole: https://www.amikit.amiga.sk/ .

Why is it bad? Genuine question, and please don't give me the "it's so unintuitive" answer, that's why programs come with documentation.

I stand corrected, I didn't know about that group policy setting.

> Surgeon workstations can absolutely be restarted once per month to install the monthly roll-up.

I was replying to the part about forcing updates. I didn't know about the group policy setting (rightfully pointed out by sp332); without it, you don't wait a month, you wait at most 12 hours :-).