Slashdot Mirror
Linux Foundation Chief: Businesses 'Will Fail' If They Don't Use Open Source Code (techrepublic.com)
The luminaries speaking at the Google Cloud Next conference had some strong words about the importance of openness, innovation, and a rich developer community. An anonymous reader writes:
First Vint Cert said there's a "thread of openness" that runs throughout the internet, adding that "the internet, itself, has open characteristics" and thrives on "permissionless innovation." And Eric Brewer, vice president of infrastructure at Google, touched on the same themes, according to Tech Republic. "Linux, Brewer said, won some of the early internet wars because it was open, but also because it was the most innovative of its time. He also said that companies should work with open source for the value of the ecosystem and community, not just the value of the code." Then Linux Foundation executive director Jim Zemlin told the audience that business models were already changing to include open source, and ultimately made the argument that organizations that "don't harvest the shared innovation" of open source "will fail."
After seeing how GNOME 3, systemd and PulseAudio have destroyed Linux's usability for me, and after seeing how Firefox has gone way down hill, I have to question the involvement of large organizations, profit-driven or not, when it comes to the development of open source software.
The best open source software I use on a daily basis is developed by a single individual, or perhaps a small team at most. This software is usable and pleasant to use, perhaps because the creators are often among its heaviest users.
The worst open source software I have had to use has been developed by corporations or large organizations. In some cases this software has been supremely disruptive, especially when it has been forced on unwilling victims, like in the case of systemd. It's really strange to talk about the "ecosystem and the community", when software like systemd has, in my opinion and experience, inflicted great pain upon both of those things.
Those things Google mentions-- like "Permissionless innovation" and the like-- those frighten the shit out of businesses who revolve around gatekeeping.
You see, to stay relevant in such an atmosphere, one has to actually be innovative, stay innovative, and be among the most innovative. That costs money and effort. Innovating early, then stagnating the market with gatekeeping and patent abuse allows them to reap big financial rewards for years while doing nothing but placating shareholders. (See, EG, the likes of Oracle.)
Google is *really* telling them that their market abuse strategy is doomed to failure, because innovators will not be discouraged by their heavy handed attempts to stop them, and the internet amplifies that innovation.
Expect lots of denial, gnashing of teeth, and doubled-down litigation in the near future.
Gnome3 and its ilk, are the result of developers (and especially designers) not listening to their userbase.
"But the menu based metaphor systems are so... OLD!" is not a justifiable excuse for not respecting user feedback about your choices as the dev team/designer.
The same same is true for things like Pottering's systemd.
"Script based inits, like found in sysv init, are just so OLD!" is not a justifiable excuse for its removal.
If you are a developer/designer, and you disagree with my attestation that just because something is old does not mean you should remove it (or replace it with something else), take this to heart:
The air you breathe now is several MILLION years old. Why not replace that old, ancient air with something new, and edgy-- like ionized plasma freshly born from inside a star!? No, you don't like that idea, because your lungs aren't able to handle highly energetic plasma? Fancy that-- your end users have systems that are not able to handle having the init system changed willy-nilly either.
Point me to the open source equivalent of SolidWorks or Adobe Premiere and then we can talk.
Only the State obtains its revenue by coercion. - Murray Rothbard
Now let's get this thinking into medical and other research, solar and other physical product development, and finally ... government. Oh yes, and that girl next door.
...omphaloskepsis often...
Gnome3 and its ilk, are the result of developers (and especially designers) not listening to their userbase.
The Gnome 3 designers aren't entirely to blame for the mess. Experimentation is a good part of innovation, or we'd be stuck using the teletype terminal. The problem is the speed with which the experiment was mainlined or adopted by the major distributions as the one and only true path to desktop nirvana. If they had allowed, say, a five-year phase-in period where features are added gradually then maybe users will get used to the new supposedly touch-friendly interface. Also a "classic" interface should have been available from day one even if it wasn't the default.
A good example of how this could be done is the evolution of the Google home page. Without Googling for screenshots, who can actually tell the difference between the Google home page now and then?
Deja vu: In the 80s we had a 70ish actor as POTUS, a woman PM in the UK, and a bald leader of that other nuke superpower
What you list is one side of the coin - trying to get too much under one hat. You'd better turn to FVWM2 or something to get a lightweight non-bloated platform.
But the other side of the coin is that with openness you get interoperability - people can build their own applications interacting with your platform. The sum of the parts is greater than the parts themselves. The alternative is a lot of manual labor moving information between systems with the result that either the job isn't done or it's prone to error as well as being a lot slower.
Just look at the Linux kernel - it's found "everywhere" these days, and is a framework that's possible to adapt to new hardware by adding new drivers and you can remove unnecessary parts relatively easy. It's the core of many different Linux distributions ranging from small ARM to huge multicore NUMA architectures. Developers of applications for the Linux platform can therefore develop on a PC even though the application then is re-compiled to be executed on an embedded system or on a massive supercomputer. That's the point behind openness, and it started almost 50 years ago when Unix was conceived because Multics was too closed. However it didn't really take off until Linux came around where people discovered an OS that could be adapted to their solution with no heavy strings attached in the form of licensing, just navigation around the GPL constraints which aren't that cumbersome compared to Oracle or SAP licenses.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Please elaborate on what you mean.
One problem for large banks is that they are tied down in systems written in Cobol a long time ago where only few persons have a good grasp of what the system do and with parts that nobody dares to touch because it works but nobody knows why since the person who wrote that stuff once has passed on to the afterlife.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Not everything works out, but the pieces that do came at the right time with the right functionality. Just because someone failed doesn't mean that you shouldn't try since you may have the correct flavor at the correct time.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
The thing is, you just just belong to a smaller user segment, that was deemed secondary to serve in order to improve the service for the primary focus groups. There isn't any conspiracy, or incompetence there. The mentioned applications were just marketed for mass needs instead of your elitistic little world.
PulseAudio has worked well for me. I have not had one single issue with it in the last 10 years or so. Systemd based systems have been more manageable, and the absolute basics like automatic service restarts are supported - unlike on initv and other legacy applications. Gnome 3 is wonderful, because it stays off my face, offers high usability, and doesn't require any fiddling out of the box. Sane defaults rule.
Banks are usually so far behind that the code that runs things is hidden behind several black boxes.
Investment banks (note, not the same thing as regular deposit banks) on the other hand are constantly pushing for faster hardware, assembly-level code at all levels to ensure their orders go out faster than their competition. That 20ms round trip time between the NASDAQ and the Banks computers means the difference of millions of dollars per second.
But banks do not, ever, benefit from open source, because they don't want to be using operating systems, drivers and software that they don't own. It's all in-house stuff.
Now, on the other hand, governments should be using open source software, it is in their best interests to ensure they don't get stuck with proprietary software vendors, and paying money for software that is often worse than off-the-shelf software. *cough*Siebel*is*awful*cough*
I've seen so many proprietary software packages that weren't in-house things from the jobs I've had in the past that I've said to myself I could write a better tool, but without having access to the API, I can't.
I think there's more an aspect of, "When people are getting a paycheck, they care less." Part of it's because following what your boss wants is not very fun.
ESR is not fashionable these days, but he has some good points about programmer motivation in the open source world.
"First they came for the slanderers and i said nothing."
let's add SELinux to that list.
You don't have to use gnome3, pulse audio, or systemd if you don't want too. There are still distributions out there that shun those. Pick you poison or roll your own.
I read at +2. If your post doesn't reach that level I will not see or respond to it.
that if you are a software company whose software doesn't fall under the "blessed trinity" then it would be SUICIDE to go FOSS as you won't be able to make enough to keep the lights on!
Ever wonder why no FOSS game has taken game of the year? Why after all these years the only "competition" to Photoshop that is FOSS is literally some kid's school project? Why all those niche applications like medical diagnosis and billing are never FOSS, or why programs like GnuCash are a bad joke compare to commercial products like Quicken and Quickbooks from a decade ago? The answer is actually quite simple which is FOSS works on the blessed trinity and if your software doesn't fit that model you have no chance to survive and your company will go under. We've seen it happen time and time again, in everything from Windows to Linux game converters to repos for commercial software to OSes themselves, if it doesn't fit the trinity model? It has zero chance.
This is why FOSS will never become the dominant license, why despite MSFT doing everything short of making a high res Goatse as the default wallpaper Windows 10 continues to grow while Linux is flatline, it all comes down to the trinity simply not working for the vast majority of software out there and without the software people want and need to do their jobs? You might as well be offering to trade their PC for a potato. For those that do not know what the blessed trinity is, its 1.- Selling services, 2.- Selling hardware, and 3.- e-begging. And if your software, which more than 95% of the software used daily by hundreds of millions qualify, doesn't work under this model? Then FOSS is suicide because you simply cannot make enough money to keep the lights on in FOSS if you don't fit the trinity model.
I really wish it wasn't so, Windows 10 is such a nightmare it actually makes the thought of the return of the Ballmernator look like the return of Steve Jobs to Apple, and Google and Apple are racing to see which one can become the most Stasi like when it comes to gathering data, but as long as FOSS is so politicized and rigid that an individual or company cannot sell more than a single copy of their software before someone else gives it away for free? Then FOSS will stay exactly where it is, a niche tool mainly used by multinationals as a way to avoid licensing fees on their servers and to not have to pay for the software which they use on their hardware...which is of course #2 on the trinity..
ACs don't waste your time replying, your posts are never seen by me.
"Anonymous Coward said: "After seeing how GNOME 3, systemd and PulseAudio have destroyed Linux's usability for me"
What stopped you uninstalling PulseAudio or using one of the other Linux Desktop Environments. Video demo of XFCE vs MATE vs KDE.
Init always had automatic service restarting, the "respawn" option of /etc/inittab...
Of course having a service automatically restart just masks the true problem - namely that your service doesn't stay running on its own for whatever reason.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
> The best open source software I use on a daily basis is developed by a single individual
From a business perspective that would be risky unless it is not in any way business critical.
After seeing how GNOME 3, systemd and PulseAudio have destroyed Linux's usability for me
Yeah damn my ability to switch audio dynamically in a modern way. Damn being able to manage system services without wading through 100 line scripts. Damn .... No actually you're right GNOME 3 can fuck right off.
are just so OLD!" is not a justifiable excuse for its removal
Fortunately for you, that was never the justification to replace them.
It's not so much about the paycheque, it's about the layers of indirection between the developer and the user. For a very small open source project, the developer and the user are the same person. The project grows and gets more users, then the developer is one of the users, but still directly in contact with people who have other use cases. Then the project grows a bit more and there are multiple developers, but they're all still users.
Then it grows a bit more, and now other people are paid to work on the project. They're paid by companies that are using the software though, so even though they're not users then their pay check depends on keeping at least some users happy. It's not ideal, but it's better than the next step.
The final step mirrors proprietary off-the-shelf software development. A company like RedHat or Canonical (or Moz Corp) starts paying developers. This company may not be using the software much, but ships a product that incorporates it. They have customers that use the software and so need to provide features that those users need, but they also need to justify why those customers should buy the new version or keep paying the support contract, so they have to demonstrate change. Once this happens, there are two layers of indirection between developers and users and the incentives are no longer aligned between the two. Software generally goes down hill at this point.
There's a related issue with open source software that's less common in COTS proprietary software: the fame issue. Once a piece of software is popular, there's a big ego boost for some people in contributing to it, because stuff that they did is widely used. There's an even bigger ego boost if a change that they made is one that everyone knows about. This gives a big incentive to change things that users will notice and those changes are not generally because the user wants them.
I am TheRaven on Soylent News
A lot of banks run FreeBSD. Quite a lot still use OpenVMS. Back end stuff varies hugely and includes Linux, FreeBSD, OpenVMS, Windows, and even some more esoteric things.
I am TheRaven on Soylent News
But the other side of the coin is that with openness you get interoperability - people can build their own applications interacting with your platform. The sum of the parts is greater than the parts themselves. The alternative is a lot of manual labor moving information between systems with the result that either the job isn't done or it's prone to error as well as being a lot slower.
However it didn't really take off until Linux came around where people discovered an OS that could be adapted to their solution with no heavy strings attached in the form of licensing, just navigation around the GPL constraints which aren't that cumbersome compared to Oracle or SAP licenses.
Here's where I like to bring up a metaphor -- I see two roles to software development: the first is to raise the ceiling -- innovate and create something better than anyone else before you, setting a new "maximum" that all software can aspire to; the other is to raise the floor -- set a new "minimum" that all software should be better than.
For instance, the existence of free implementations of quicksort, bubble sort etc raise the floor, because now everyone can write software that sorts data with the same efficiency. Meanwhile, a custom-coded adaptive sort for an accountancy system raises the ceiling, because competitors have to try to improve the performance of their sorts to be seen as being as good.
I mostly like the GPL, but the problem is that it rarely if ever raises the floor, because copyleft licenses are not completely open in the same way the C standard libraries are. Yet there are components within most GPL projects that could be used generically and could be part of the common floor, but it will never be part of the common floor until all contributors have been dead for 70 years, and given that many contributors are pseudonymous or have incredibly common names, there's no way of doing due diligence on that... not that it is likely to be relevant by that point.
Imagine if the GPL was replaced with a copyleft license that expired after 10 years -- imagine how big a common floor we'd have. All the code released would be so old that it wouldn't be of particular interest to big companies, but people would be able to revive long-dead projects as commercial packages or as labours of love. We could go back and build libraries out of the proprietary code of older projects. A higher floor.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
Meh. I used Gnome 2 for years and was shocked as anybody at Gnome 3 but gave it a chance. Now there is no way in hell I would ever go back. It's simply fluid and suits my workflow. I think there just way too many people who would gladly live in the past without ever taking a chance on something new. I liken it to the XP users. They were happy (hey I was too) but c'mon, Windows 7 blew it away in terms of usability. I would argue for Gnome 3 all the same and even if not that, systemd (for all its faults) is better than sysvinit.
Gnome3 I can understand, but just use Kde instead.
But how exactly did systemd and PulseAudio destroy usability for you? Personally I found they make my desktop system much better.
However handing respawning via inittab is like wielding a sledgehammer in a glass shop. With systemd you can enable/disable this with a easy setting on a per daemon basis and also define "only respawn X number of times during Y number of seconds" among other things.
Regarding your second opinion I tend to agree, however there exists plenty of daemons/services where a pure restart does no real harm (say a webserver, dns server and so on) and one does not exclude the other, i.e just because your daemons respawn automatically does not mean that you also dos not look into why they did.
Which have nothing to do with the issue at hand, this is about respawning crashed/downed services and not respawning just for fun.
The problem is the speed with which the experiment was mainlined or adopted by the major distributions as the one and only true path to desktop nirvana.
I don't know to which "major distributions" you refer, but Debian descendants still provide the more traditional look and feel of Xfce. To put Xfce on your Ubuntu box, for instance, run sudo apt install xubuntu-desktop
Businesses 'Will Fail' If They Don't Use Open Source Code...thats a hell of a marketing strategy but you have to remember, 7 billion people without a Start button when they sit in front of a monitor. The first think they do is pick up the phone and call their IT department for help. For the past 23 years, the global general public does not want to be educated to use Linux, they just want to retire using Windows.
--Yah, I didn't like Pulseaudio for a while but it actually comes in handy for HDMI video output and volume control (pavucontrol). Systemd I don't like (and use the Antix distro to get around it) and haven't used GNOME regularly since about 2.4.
.
== WolfriderV6 == I'm willing to admit that *I just might* be wrong... Are you??
There's a lot of truth to that. Productivity tends to scale with N but communications overhead tends to N^2. So at some point as N increases the communications overhead will swamp actual productivity.
When employers aren't involved, eventually some subset of the developers will just do the right thing by themselves and the project moves forward. Otherwise, management enforces paying the communications overhead and nothing useful happens.
Of course, in those limited cases, a small simple C program can take care of respawning without disrupting everything else in the system. Just drop it into the init script.
It's trivially easy to dump pulseaudio and GNOME3, but systemd is somewhat harder to get rid of since it likes to dig it's tentacles into everything.
Or you are prepared to take over should that individual decide to retire from the project (not usually an option with proprietary software) or the software is sufficiently mature that further development is not needed (actually fairly common in business software). Again, advantage to Free software since licensing extra copies isn't an issue.
But it's a lot cheaper than starting over from scratch if a proprietary vendor decides to cancel the project.
Well just for fun is how I would describe the "just restart it!" crowd that AC was talking about so I don't see your problem.
For this particular little feature of something like systemd and upstart yes, but then you have to make your solution distro agnostic, work with daemons that fork or not fork, that crashes in such a way that it brings the shell down with it and all of a sudden that small and simple program is not so small and simple any more.
I once wrote one in 10 lines of C that woule compile on every distro as well as Irix and Solaris. So very hard!
You have a serious point to make here - What is the point of effort to create a program if the life of the OS is too short? The application you made may very quite well become useless or so buggy, that no one wants to use the once useful program? Or is may be so bothersome to make it work with the new version that it does not free your time up for anything else, or improve features on your program.
UX is a very useful term. HCI people who know what they're talking about don't use it, so anyone who claims to be a UX expert has helpfully self identified as someone that it's safe to ignore.
I am TheRaven on Soylent News
Obviously after a panic you have to boot, but that does not mean the problem is not going to be addressed.
CLI paste? paste.pr0.tips!
With systemd you can enable/disable this with a easy setting on a per daemon basis and also define "only respawn X number of times during Y number of seconds"
Indeed. Like you can do with init. But let not get facts in your way of spreading systemd propaganda.
CLI paste? paste.pr0.tips!
Which is why I specifically talked about copyleft licenses.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
Or the userbase has shifted.
Once upon a time, it was acceptable that devices could monopolize the audio device. No longer. Once upon a time, you could count on audio devices being static. No longer. Once upon a time, you could count on users dynamically adding and removing audio devices and expecting those devices to be usable without the underlying program opening them explicitly. No longer.
It's things that Windows and macOS do just fine. You connect your Bluetooth headset (or USB headset) and automagically, your communications apps switch over to using them without you closing them, or without them explicitly opening them - they opened the audio device and didn't care which it was. The user may use the built in microphone and speakers, then wanting a bit more privacy, plug in a headset (USB, Bluetooth, it doesn't matter), and then continue their conversation in private without doing anything else. The communications app didn't close and was reopened by the user - the user simply continued their existing conversation just fine, using a new audio device that wasn't there when the app started. And without special coding on the app's part to scan for new audio devices and ask the user if they wanted to switch over to using it.
Once upon a time, network configurations never changed. No longer. Once upon a time, when you connected to a network, it was the same network. No longer. Once upon a time, when the network connected, you could use it immediately. No longer.
Users connect to wifi promiscuously. One moment, they may be at work and on the corporate LAN over WiFI. The next moment they may be at Starbucks - and seeing that the connection is open, the OS should offer to launch a VPN client (no OS does this, yet, though Nexus/Pixel Androids do ask sometimes) to connect back to the office, or offer to secure the WiFi connection. And of course, the firewall should be enabled at its strictest setting.for out-of-LAN networks.
Likewise, script-based inits make no sense - why do you emulate what init can already do - maintain daemons? If a daemon crashes or exits, init (sysvinit) can already relaunch it. And if it dies too fast, init can pause launching it for a few minutes so you can have a system youc an debug with. Plus, it keeps track of the runlevels too, so you don't have to make sure your S/K scripts balance. (And switching is so inefficient when you have to K the service, then switch over and then relaunch it afterwards if both runlevels have the same service).
Of course, every other major Unix-based OS has their own system, which should say something. (Android as well).
Just because you liked how simple things in the past were, doesn't mean today they're still relevant. Sure it's nice, but the demands of a modern OS have gotten much more complex.
Of course you can, but you also have to write quite a bit of shell script in order to do that and not just alter a simple setting. And you would still fall through all manners of possible problems with pid-matching and so on that have plagued any such prior attempt via inittab.
And if it never got the SIGCHLD since signals does not have a delivery guarantee under any OS how well does your 10-line fork+execve+waitpid program work then?
And what if the daemon in question does a fork of it's own then your 10-liner gets the SIGCHLD while the daemon is running just fine and you will never get the SIGCHLD from the grandchild so you now have to add several lines more to read in a pid file and also hope that the daemon in question stores the running pid in such a file and further you have to hope that of the grandchild dies then another process that is spawned in between does not get the same pid as your grandchild. At the same time something like systemd handles all these corner cases and more due to it actually being init and not a separate process/script.
In short, the reason to implement functionality such as this into either systemd or upstart is for the distro maintainers to be able to support respawning for all different kinds of strange daemons. I get that you #1 don't want respawning to begin with and #2 only have to support a handful of such daemons but I do hope that you understand that there are others with complete different needs than yours?
Otherwise we end up with horrendous examples like the mysqld_safe script which was Oracle/SUNs try at doing this distro agnostic with sysvinit. They didn't exactly succeed to put it mildly.
It never missed. Of course it was written for the daemon it was respawning.
However, now that cgroups is a thing, I could write one that never misses for any program. It would still be a lot less disruption to just drop that in than it is to use systemd.
Or, I could just use PR_SET_CHILD_SUBREAPER to make the respawner instance become the parent of any children of the daemon so that I just have to see if I still have child processes. Not available when I wrote the 10 liner, but available now.
Of course, systemd isn't a perfect solution either. For example, if a daemon forks and exits and then the child process gets stuck but doesn't terminate, systemd won't know about it. A custom restarter could check for that condition as needed.
if (ch->count >= MAXSPAWN) {
initlog(L_VB,
"Id \"%s\" respawning too fast: disabled for %d minutes",
ch->id, SLEEPTIME / 60);
That said, I'm not sure why/how you need pid matching for a process that crashed and hence does not have a pid anymore.
CLI paste? paste.pr0.tips!
pid-matching is needed in the situation where the underlying deamon forks and thus the daemon is running as a grandchild to your monitoring process. Then the only way that your process can see if the grandchild is running is to check if the pid that it stored in a pid-file is running, however due to the limited space of pids (they are only 16 bits) there can spawn a different process that gets the same pid as your grandchild between the moment the grandchild crashes and your process detects that it's down which would make your monitoring process erroneously believe that the grandchild is still running.
This all becomes moot of course if you are init since you then have complete control over grandchildren, even more so if you also are the cgroups master.
Well if you only care about deamons that you write your self then yes this is a no problem as you write but as a distribution one have to think about all those strange and different daemons out there.
Of course, systemd isn't a perfect solution either. For example, if a daemon forks and exits and then the child process gets stuck but doesn't terminate, systemd won't know about it. A custom restarter could check for that condition as needed.
For the random daemon out there yes but it the daemon supports systemd it can send heartbeats to systemd with "sd_notify (0, "WATCHDOG=1");" in order to catch a stalled deamon. systemd itself can also send heartbeats upwards to a harware watchdog so your whole server gets a reboot if the whole system stalls.
You missed it! I could use the very code that systemd uses only isolated as a small restarter utility and get the same results with far less disruption to the system as a whole. It's what they should have done in the first place. The only reason systemd is better at restarting than the old restarters is that it can rely on cgroups to do the heavy lifting and that didn't exist years ago.
It's the same reason systemd hasn't tried to consume *BSD or Mac.