Linux Turns 25, Is Bigger and More Professional Than Ever (arstechnica.com)
The Linux operating system kernel is 25 years old this month, ArsTechnica writes. It was August 25, 1991 when Linus Torvalds posted his famous message announcing the project, claiming that Linux was "just a hobby, won't be big and professional like gnu." From the article: But now, Linux is far bigger and more professional than Torvalds could have imagined. Linux powers huge portions of the Internet's infrastructure, corporate data centers, websites, stock exchanges, the world's most widely used smartphone operating system, and nearly all of the world's fastest supercomputers. The successes easily outweigh Linux's failure to unseat Microsoft and Apple on PCs, but Linux has still managed to get on tens of millions of desktops and laptops and Linux software even runs on Windows.Do you use any Linux-based operating system? Share your experience with it. What changes would you want to see in it in the next five years?
Of course it is "More Professional Than Ever". Its a corporate led project now, not a hobbyist led project anymore. Most of the development is corporate or corporate sponsored, either way corporations guide Linux's development.
I remember when Linus posted it. I downloaded it and played with it a bit.
When Slackware 0.99a came out I gave it another try. It was not long before I was converting my Minix boxes at the house over to Linux.
In 1995 I switched from Windows 3.11 to Slackware and never looked back. To this day I run linux on all my systems at home save a small laptop that runs Windows XP though it is just to manage the spectrophotometer which does not have a linux driver.
Linux has come a long way and I am always amazed at how much of the world runs linux from Cell Phones, to routers, to supercomputers.
actually, yes, the kernel itself could contain certain web servers, so brush up on your tech knowledge before spewing, please
Linus accepted the systemd hooks, for good or bad. I hate the stuff but I can blame Linus. Worth noting I admin hundreds of servers without systemD, in about two years my employer will have to make a choice about that
Not seeing evidence of your corporate control, rather Linus accepting contributions.
Ardour is great, and so is Reaper. The existence of a solid DAW on Linux isn't the issue at this point.
First, one of the major issues is inertia - Logic Pro, Ableton, ProTools, Cubase, Sonar, and FL Studio are all respected names in the field, with lots of users, forums, and ecosystems around them. Audio engineering is very susceptible to a herd mentality, because anyone who uses something different will be told to join the herd, rather than getting actual support.
Next, audio engineering is much more hardware dependent than most CS/IT disciplines. For us, 'input' basically consists of keyboards and NICs, which are interchangeable. Pro audio involves audio interfaces from Tascam, Presonus, M-Audio, and FocusRite, with MIDI controllers ranging from Korg/Yamaha keyboards to guitar pedals and drum pads. We'll circle back to the interface problems in a moment, but the MIDI controllers are largely USB now, meaning there are abstraction layers that may require specialized drivers, mapping software, and plug-ins.
Back to the audio interface question, amongst the major things we have here is that Jack/Alsa are fine for desktops with Realtek chipsets, but when you're dealing with thousand dollar interfaces that can record sixteen channels of audio in real-time with 1ms latency, Jack and Alsa just don't cut it. OSX has CoreAudio and Windows has ASIO, both of which are industry standards that work with those interfaces. Linux would need something similar to it, but even if such a thing were to come into existence, support by the hardware OEMs is certainly not coming into place overnight. Meanwhile, those OEMs need to sell gear, which means that CoreAudio and ASIO handle over 99% of the market, and no one seems to be chomping at the bit to write yet another audio system for Linux to even provide a viable target. Reaper and Ardour could well start on that, but now you have DAW devs stuck writing middleware that already exists on Windows and OSX.
I look forward to it happening, but it's a pipe dream right now. Hardware OEMs are targeting ASIO and CoreAudio, plug-in writers are targeting Ableton, Protools, and VST hosts, industry standard DAWs are targeting Windows and OSX, and a soup-to-nuts Linux ecosystem would require cooperation from everyone at the same time for a market segment that's super picky at best.
Wake me up when even Windows follows that paradigm. In fact, Microsoft is, at least in the enterprise, moving explicitly away from the GUI, and pushing Powershell for many tasks. But really, it's always been that way. GUI configuration tools in Windows have always presented only a portion of the configuration options, and many settings have had to be adjusted via the Registry. Even with GPOs, many settings can only be accessed via the Registry.
Like any system, whether it be Windows, OSX or Linux, everything works great out of the box... until it doesn't, and at that point the user is forced to go to some pretty daunting places. I've had enough fun trying to install drivers in Windows, or trying to solve problems on everything from screwed up profiles to getting the damned thing to time sync properly to know that Windows "ease of use" is more a marketing slogan than reality.
The world's burning. Moped Jesus spotted on I50. Details at 11.
The other problem is resistance in the Linux community to complex tools - because the problems are complex to solve. Even if you apply the "do one thing and do it well", it ends up as a complex tool (see SystemD). And no, sysvinit scripts are not the solution (question - why does /sbin/init provide a perfectly usable daemon manager that no one uses? I mean, it will monitor daemons, if they die, it will restart them. If they die too quickly, it will pause restarting to let the admin have CPU time to fix the problem).
System initialization isn't easy - Apple has tried many different forms of system initialization daemons until settling on launchd (they started with sysvinit at first, then migrated to SystemStarter and a couple of others). And the BSDs have tried to port launchd over as well.
Then there are other use cases - networking for example. NetworkManager is a solution to a problem users have - they may connect to different networks with different network settings. Because without it, handling the simple case of a user going from home wifi to public wifi is much harder. At least to Linux's credit, when it detects public wifi, it can auto-start a VPN client, or even prevent unencrypted traffic in the narrow window between connecting to public wifi and before the VPN starts up. Or even something as minor as going from static IP to DHCP.
Then there's PulseAudio, a framework made necessary because users are complex. Such as being able to switch audio devices while the program has the audio device open. E.g., VoIP - user might be having it on the main audio device waiting for it to ring. The moment it does, users plug in a USB headset (new audio card), and have the call audio automatically routed to the headset without the controlling application (VoIP program) having to do a thing. Or a user switches from onboard audio to a Bluetooth headphone and being able to do it transparent to the player application.
Of course, there's a Linux that does all this transparently to the user - we call it Android. And all this stuff is complex because it has to be - there's no simple way to have a system do these tasks.
I am a big fan of Linux in technical terms, but not a big fan in terms of UX (basically, the social end of computing, where collaboration across large teams is basically required for a high quality product).
Android is illustrative of what Linux *can* be, but on the desktop has never managed to be because of the obvious differences between the social (i.e. people and hierarchy) infrastructure behind Android vs. behind the Linux desktop.
I used Linux from 1993 through 2010. Early on I used the same .twmrc files with TWM that I used on my HPUX and SunOS boxes at CS school. At the time, the Linux desktop was *light years* ahead of the Windows desktop. 16-bit color, high resolutions, fast, lots of very powerful applications from the Unix world and experimental desktop projects like InterViews that seemed very promising. People with MS-DOS or GEM or Windows 1/2.x computers were envious.
Later on I used FVWM. Then I switched to KDE in the KDE Beta 3 era. But then (mid-late '90s), Linux on the desktop had already been outrun by Windows 95 and Mac OS. The level of integration amongst services and components wasn't that of a coherent system like it was for Mac OS and Windows; the Linux "computing is a network" philosophy—very good for things like business and scientific computing—was obvious in comparison.
When KDE 4 was released, I tried to use it for a while but it got in my way. I had to rebuild my entire desktop over and over again as objects were lost, lost their properties, etc. After about two weeks on KDE 4 during which I mostly nursed KDE along rather than doing my actual work, I switched to GNOME 2.x. I see that as something of a golden age for desktop Linux—basic parity with what was going on in the Mac and Windows worlds if you used a polished distribution like Fedora. Install was different, equally demanding of skills, but the actual install and setup process for the desktop OS on a bare machine involved approximately the same amount of work as was true for Windows, and the result was basic feature and experience parity.
Then, the bottom fell out. I suspect that a lot of the need for the Linux desktop with experience parity to Windows was met by an increasingly revived Mac OS, and users flocked there. Myself included, in the end.
GNOME 3 came out and KDE 4 was finally becoming usable and there was something of a battle, but both were behind the curve relative to the stability and seamlessness of OS X, and OS X had end-user application developers already. They screamed and moaned during the transition from legacy Mac OS, but most of them hung on and redeveloped their applications for OS X, and there were a bunch of new application developers to boot.
On top of that, the major applications of the business and academic worlds made their way out for OS X as it became a viable platform. You now had a seamless desktop OS that offered all the big brands in user applications, plus stability, plus easy access to a *nix environment and command line if you wanted it.
I was busy fighting Linux during that "instability era" just as KDE4/GNOME3 happened and duked it out. Things were changing very quickly in many facets of the Linux base installs, in hardware, etc. and every update seemed to break my Thinkpad T60 which at the time ran on Fedora. I was spending a lot of time fixing dotfiles and scripts and trying to solve dependency problems, etc. Meanwhile, lots of new things that were starting to become commonplace needs (cloud services, mobile devices, etc.) didn't yet work well with Linux without lots of command line hacking and compiling of alpha-quality stuff from source.
A couple of fellow academics kept telling me to try Mac OS. Finally I did, I installed a hackintosh partition on my T60. By mid-2010, I realized that I was using my OS X boot, along with the GNU tools environment from MacPorts, far more than I was using the Linux partition, and that there were Mac applications that I was *dying* to start using on a daily basis, but ha
STOP . AMERICA . NOW
We are still seeing this shit after MS Powershell came out?
Look up "grep", "sed" and "awk" and you'll see why some people dealing with CSV files or similar are happy that there is a command prompt instead of having to wait for someone to write a special program for them.
"Even if you apply the "do one thing and do it well", it ends up as a complex tool (see SystemD"
Thats because systemd isn't doing one thing and do it well, it is trying to do a lot of stuff and not really doing it well at all. systemd is more like a one size fits all hat. It doesnt really fit anyone well. Systemd is both needlessly complex and shit.