191
192

A Generation Lost in the Bazaar (queue.acm.org)

cl0p3z が 投稿

全ての 192 コメント
並べ替え:
ベスト
ベスト
トップ
新着
注目
論争中
古い順

[–]jra_samba_org 44 ポイント45 ポイント  (6子コメント)

(Comment I added to the article):

Faulty memory ? :-)

"Instead of standardizing how to do that across all Unixen - something that would take just a single flag to the ld(1) command"

I chuckled when I read this. Exactly how did the author expect this to get done across the UNIXes of the day ? By persuading Sun ? Or AT&T, or maybe the OSF ? Or possibly HP ? Or Fujitsu or or IBM or any of the other of the hundreds of warring UNIX companies, all of whom HATED each other and saw every single difference as an advantage for their "side", every difference as something to celebrate in making software difficult to port ?

Does the author not remember these days ? I certainly do :-).

autoconf fixed a real problem, and still does today. After all, linker flags in FreeBSD are still different from GNU ld, which is as close to a standard as exists these days (and I know because I have to work around them).

Adopt a GNU-derived solution on a *BSD platform ! Sacrilege ! Burn the heretic :-).

Such attitudes still shine out loud and clear from the author.

There is a reason that Microsoft Windows won the UNIX wars. We would all do well to remember it.

[–]sinxoveretothex 8 ポイント9 ポイント  (5子コメント)

Insightful comment. I would be very interested in knowing what Poul-Henning would respond to that :) .

There is a reason that Microsoft Windows won the UNIX wars. We would all do well to remember it.

Can you expand here? I'd be interested in reading some more about that.

[–]jra_samba_org 23 ポイント24 ポイント  (4子コメント)

I remember being at a X Windows conference in 1992 in San Jose (or around that time), where Bob Scheifler (sp?), one of the authors of X (and one of my idols at the time, but not for long :-), verbaly berated an Adobe developer who was asking him how she could use X to talk to the printer, as under MS-Windows they simply rendered using GDI, which the Windows printer drivers would then convert to whatever page description language was used by the printer.

He replied "Why do you want ME to help you talk to a printer. That's not MY problem".

I remember thinking "oh god we're finished, I might as well learn Windows", which I subsequently did (although Win32, Win16 was just too horrible to contemplate - anyone remember "char far * pascal" ? :-).

[–]sinxoveretothex 4 ポイント5 ポイント  (2子コメント)

Is that why you think Windows won the UNIX wars?

[–]jra_samba_org 22 ポイント23 ポイント  (0子コメント)

Well it's illustrative of the attitude of the UNIX greybeards at the time. Making stuff that was actually useful for users was considered unimportant next to elegance and sophistication in programming. Microsoft never made that mistake with Windows - elegance be damned - does it do what the customer wants by any means necessary ?

They ended up with a wonderful system no one wanted to sit in front of and use (except for weirdos like myself :-).

That's one of the reasons I have a LOT of time for Canonical with Ubuntu and Android of course.

Whatever their other flaws they have made UNIX into a system that ordinary uses actually like using.

[–]rodgerd 2 ポイント3 ポイント  (0子コメント)

I have a somewhat different perspective that Jeremy, since I was a grunt ops guy/junior sysadmin for most of the 90s, but I'd agree with his conclusion. I worked in publishing, and in the first half of the 90s a huge amount of the specialised systems ran on Unix systems of one sort or another. The difficulties of maintaining ports (and probably sweetheart backroom deals between vendors) meant that from a customer perspective you'd have an Irix RIP powering your colour lasers[1], maybe a SunOS RIP for your film printers, perhaps some AIX workstations for your ad layout systems and OPI, and Solaris for your newer bromide units.

The userlands in all these systems were different enough to be a pain to keep current on, and you'd end up having resellers and customers hiring a very high ratio of Unix ops people to servers.

Windows NT went through this industry like a dose of salts. Software vendors could write once, compile for Intel and Alpha (the main two architectures I saw in production) and have a very limited set of support hassles. Resellers needed one set of technical support skills, as did customers. The fact that NT cost a fraction of the proprietary Unices, even on Alpha hardware, was a nice bonus, but it paled compared to the support headaches.

By the end of the 90s Unix was in a death spiral. Free clones were pretty much the only reason *ix survived. I find frankly disturbing echoes of the era in peoples' determination to keep special snowflake init mechanisms, config layouts, and userland behaviours alive so every Linux distro is painfully different, TBH.

[1] Then an extraordinarily expensive bit of hardware.

[–]bryteise 0 ポイント1 ポイント  (0子コメント)

Anybody who ever needed to care about segmented memory has my condolences.

[–]clofresh 29 ポイント30 ポイント  (76子コメント)

I've always marveled at how many layers upon layers our modern software infrastructure is built upon. Are there any promising efforts to truly start from scratch?

[–]gaggra 24 ポイント25 ポイント  (19子コメント)

There's always Plan 9, the second-coming of Unix, and Inferno, the lesser-known virtualized child of Plan 9. I can't think of another *nix-like system that could be said to "start from scratch", but I'm sure someone will correct me.

(Actually, talk of Plan 9 links back to the other threads of discussion happening here about Javascript, and Firefox dependency bloat. Plan 9 maintainers saw how terrifying web browsers were, and decided it would be much easier to port the Plan 9 userland to Linux/BSD, rather than port a modern web browser to Plan 9.)

[–]Viceroy_Fizzlebottom 23 ポイント24 ポイント  (17子コメント)

Plan 9 suffered from two major problems:

1) Marketing -- there was none

2) UNIX was good enough

Not too mention development has slowed to a crawl, etc.

The problem with starting from scratch is applications. You have this great new operating system that can't run anything because nothing has been written for it yet because it was a from scratch project. It becomes a chicken-and-the-egg problem.

The only way I could see the computing world starting from scratch would be a new radical form of hardware that REQUIRES a re-think on how software is written. Memristors could be a start to that, but I honestly don't think we'll really see change until/if pure optical computing takes off.

[–]gaggra 13 ポイント14 ポイント  (16子コメント)

Memristors could be a start to that

Nope. HP is already removing that opportunity at a fresh start by porting Linux to their architecture. Better than a fresh but closed source OS, I suppose.

I can't see any easy escape. I imagine we will haul ourselves into the future the same way a man scales a cliff-face. Linux will be the foothold of familiarity that drives adoption of memristors. Once the market is clinging to memristors, we will slowly swing from Linux to the next great memristor-based operating system. And so on, and so forth.

[–]ewzimm 12 ポイント13 ポイント  (8子コメント)

HP has stated that Linux is meant to be a temporary, transitional step to their next-gen OS. Of course, there's always the chance that LInux will be good enough and become popular.

[–]jp599 5 ポイント6 ポイント  (0子コメント)

HP doesn't have the will to actually create a new, good operating system. In the 1970s and 1980s when there were still labs doing pure research like at Bell Labs, then that was possible. HP these days is all about turning a quick profit for the next quarter. "Fire all the unnecessary workers in the UK, because they cost too much." That sort of thing. "Abandon VMS because it costs money and the customers can be bullied over to HP-UX and Linux." Seriously, HP is utterly incapable of solving big software problems like this.

[–]gaggra 7 ポイント8 ポイント  (6子コメント)

...is meant to be a temporary, transitional step to their next-gen OS.

Sounds like they're letting the fox into the henhouse. Linux is certainly "good enough", and certainly popular already.

[–]Decker108 13 ポイント14 ポイント  (1子コメント)

"Sure, you can run Linux on these memristor-computers today, but we've got this insanely great, completely new, closed-source, expensive as all hell OS coming out next week!"

[–]gaggra 2 ポイント3 ポイント  (0子コメント)

Indeed. Linux, the proven, enterprise-ready OS you probably already have software working on, and have people trained to use...

...or the experimental new system that will require porting work, retraining and all sorts of downtime during the transition!

HP might produce something fantastic, but the enemy of greatness is something that is just good enough, and Linux is just that.

[–]ewzimm 2 ポイント3 ポイント  (3子コメント)

It's good enough for current architectures. With such a radical shift in architecture, an OS built for memristors might be orders of magnitude more efficient. There's nothing in Linux, for example, to enable using the storage medium for computation.

[–]uep 0 ポイント1 ポイント  (2子コメント)

There's nothing in Linux, for example, to enable using the storage medium for computation.

I could see that being as simple as a new kernel module. Things have been added via a kernel module that seem like radical changes, but it turns out they can just be plugged in.

[–]ewzimm 2 ポイント3 ポイント  (1子コメント)

It's possible. We just don't know how it will turn out yet. But this could be one of those instances where microkernels or something even more radical actually matter. Maybe it will be time for Hurd to shine! That's what's attracting so many people to the project... not knowing what is going to work. I wouldn't rule Linux out, but it's far from a sure thing.

[–]uep 1 ポイント2 ポイント  (0子コメント)

I think Linux will very quickly adapt to be usable on such a platform, but I agree with your general spirit; it's possible that memristors will create a big new opening for alternate OSes.

Personally, I think there is plenty of space in the current environment for alternative OSes. Unfortunately, some of the really interesting alternatives' ecosystems never took off.

[–]disintegore 6 ポイント7 ポイント  (6子コメント)

I feel like Linux is bound to become the huge abomination/primary obstacle to progress that Windows currently is should it ever disappear.

[–]traxislyte 13 ポイント14 ポイント  (4子コメント)

It happens with most successful technologies. It's called the Innovator's Dilemma.

Basically, you've got this really successful tech and eventually it needs to be updated. You can either keep holding on to the older (and older) tech and the current userbase who want the same thing, or you can innovate to try to gain more users, but you risk alienating the users that made you successful, who may then leave you and destroy your organization in the meantime.

[–]strngsvlmstng96 4 ポイント5 ポイント  (3子コメント)

Sounds an awful lot like gentrification, except with software instead of cities.

[–]Arizhel 1 ポイント2 ポイント  (2子コメント)

Maybe a little bit. Usually with gentrification, however, a bunch of richer people are moving into a neighborhood and then pushing out the poorer residents. The main problem with this, from the perspective of the locality and its local economy, is that many of those people were also the local labor force, and the richer people moving in aren't going to replace them in their menial jobs. So now the local businesses have to get people to commute in to take these jobs. Depending on how far away affordable housing is, this may or may not be a big problem. Generally, it seems that what happens is local businesses raise their wages some to compensate for this, so workers are more willing to make the trip just to get the pay bonus that they won't get in a cheaper area that's closer to home. The local businesses jack up their prices to make up for this, and then even more because all the locals have lots of money. Then the people with money who moved into the area bitch and complain because it's more expensive than when they first moved in.

[–]strngsvlmstng96 1 ポイント2 ポイント  (1子コメント)

All of that is true, but I was just saying that this resembles gentrification in that the core user community is being pushed out in favor of the new people.

[–]Arizhel 0 ポイント1 ポイント  (0子コメント)

Yes, I'd agree with that.

However, there's one caveat, I think: with gentrification, there's an absolute guarantee that you'll have new people. New (richer) people are moving in, and that's what's causing the gentrification. Without them, there would be no gentrification and the consequent rise in prices in that area. However, with software, the innovator/updater is hoping that enough new people will join in to replace any older ones who leave. There's no guarantee of this, and instead, they could wind up screwed because too few new people come to make up for all the pissed-off older users.

So the cause/effect relationship is reversed in these two situations.

[–]pseudopseudonym -2 ポイント-1 ポイント  (0子コメント)

I would welcome this, though.

[–]jp599 7 ポイント8 ポイント  (0子コメント)

Plan 9 was beautiful and really simple, and it only had something like 51 system calls. Linux has over 300. FreeBSD has over 400. When the Plan 9 team read a sentence that Linux has "only hundreds" of system calls, they laughed and put in the quote to their "fortune" file.

The whole goal of Ken Thompson and Dennis Ritchie was to make everything as simple and flat as possible, with the smallest number of simple, powerful, and flexible primitives. Unix works pretty good for that on one system in an old timesharing environment. The Unix team did not like Berkeley sockets, though, because they were ugly and complex, and did not fit in with the rest of the system. They started Plan 9 to make networking and distributed computing fully integrated into the system primitives, especially the filesystem.

Edit: FreeBSD has over 500 system calls (!).

[–]lykwydchykyn 14 ポイント15 ポイント  (6子コメント)

Anyone can write a "simple" OS that works with one set of hardware and doesn't have to interoperate with anything else.

Then people start whinging that it doesn't run on my-hot-new-hardware or open files from WonderSoft McOfficeSuite or stream HD video from NutFlix.com.

Then you, the developer, get to decide if you want to start writing support for every piece of hardware, every file format, every streaming protocol, and every open standard from scratch, or port readily-available open-source code to do the trick for the low low price of dependency bloat.

[–]gondur 4 ポイント5 ポイント  (1子コメント)

Anyone can write a "simple" OS that works with one set of hardware and doesn't have to interoperate with anything else.

You talk exactly about templeos, all unneeded abstraction & interfaces removed. Beautiful simplicity.

[–]gaggra 6 ポイント7 ポイント  (0子コメント)

Terry? Is that you?

[–]disintegore 1 ポイント2 ポイント  (3子コメント)

This is why we have drivers, APIs, etc.

[–]lykwydchykyn 3 ポイント4 ポイント  (2子コメント)

Right, and those things are layers of abstraction.

An API is an abstraction between what code needs to do on a platform to accomplish a task, and how a programmer wants to think about that task. A driver is an abstraction between the particulars of a piece of hardware and a standardized interface for the OS.

This is how abstraction layers form.

[–]disintegore 2 ポイント3 ポイント  (1子コメント)

Sure, but there are necessary abstraction layers and that article mostly complains about what isn't.

I guess you're telling us that any effort in "starting from scratch" would inevitable lead to the same thing due to the massive amount of fringe cases and corporate bullshit that would need to be respected?

[–]lykwydchykyn 4 ポイント5 ポイント  (0子コメント)

Unless you can write it overnight, then yes. The thing is, over the course of the years it takes to develop a codebase, things change. Platforms change, OS's change, CPU speeds change, programmers change.

Then there are circumstances. We need to ship this thing, but there are upstream libraries that aren't doing what they're supposed to. The build fails on one of the three operating systems we need to support. There isn't a library function for (feature) on (platform). Somebody writes a quick hack that fixes it, and it sticks.

It would be easy if we knew today the abstraction layers we're going to need to solve all the computing problems for the next 20 years. We don't though, so we have to make the best of it.

[–]andermetalsh 4 ポイント5 ポイント  (18子コメント)

HaikuOS|BeOS

[–]clofresh 1 ポイント2 ポイント  (12子コメント)

Cool, I had heard of BeOS a while ago but didn't know it still lived on in HaikuOS. Haiku seems like just what the article's author want. Found this on their forums:

Our rule is "sane defaults, not maximal configurability". For Haiku to introduce a configurable option, there must be a strong disagreement between devs on how things should work. This is how we got optional focus follows mouse, and modifiable window border colors.

More options means more cases to test for applications. You know how that goes on Linux: your app must render properly with dozens f different GTK or Qt themes, might behave differently when the window manager is compositing, and can't rely on the window manager allowing some features (for example having a window resize itself isn't possible because of tiling window managers).

On Haiku we have a standard window manager applications can rely on. This allows the applications to pin window to workspaces, stack windows together programatically, make sure alerts and other modal boxes show up at the right place (above the window that triggered them), etc. As soon as you start ading configurability, apps will have to be tested in more different cases, and will have to handle them all.

[–]andermetalsh 3 ポイント4 ポイント  (0子コメント)

Haiku , if maximalist, is minimal enough even for very low end sistems.

[–]TheFlyingGuy 1 ポイント2 ポイント  (10子コメント)

It also makes it so that if you have a problem with a tiny part, you have to throw out the entire OS, or maintain your own patches. A very Windows solution, that GNOME also seems to be adapting, not my kind of place to be.

[–]Arizhel 1 ポイント2 ポイント  (9子コメント)

Exactly. Flexibility trumps simplicity, and as a result, how many people do you actually see running HaikuOS? And look at all the hordes of people abandoning Gnome and Windows.

(To be fair, Windows has more configurability than that, plus it's not hard to add extra software which significantly changes the behavior of the window manager, though of course it's not supported and may have some unintended side-effects).

[–]Negirno 2 ポイント3 ポイント  (1子コメント)

A regular user most of the time doesn't even know what Linux is, much less know about Haiku. But even the more knowledgeable ones, who want a better libre desktop looks a Haiku with doubt.

The problem with haiku is:

  • It makes harder (or even impossible) for tinkerers to strip all the unnecessary "desktop bullshit" and have their favorite vim/ratpoison or any other minimal WM instead (I assume that's partly what you said);

  • It has its own API and graphical toolkit which pretty much incompatible with everything (GTK, Qt and various other stuff common in FOSS-land), so there's almost no modern applications for it.1 Instead, you have to use BeOS apps most of the time, but those are mostly abandoned a decade ago.

  • And there are patent-issues, too. The BeOS API is supposedly a property of a company, which currently let Haiku developers do their thing, but who knows what the future brings?

  1. For example, if you want to use Gimp, you have to either download the ancient looking 1.2 version from BeBits, or get the TiltOs packages, which is basically KDE apps compiled on Haiku, and has a more recent version of Gimp, but not the most recent which has the single window interface.

[–]andermetalsh 0 ポイント1 ポイント  (0子コメント)

You have ArtPaint and the default painting program.

[–]DevestatingAttack 2 ポイント3 ポイント  (4子コメント)

There are pretty decidedly not hordes of people leaving Windows, and if they are, what the hell are they leaving it for? Not Linux; the number don't bear that out. Mac? Do you believe that Mac is more customizable than Windows? Or GNOME? Android tablets? Is that more customizable than anything?

[–]tidux 2 ポイント3 ポイント  (2子コメント)

There are pretty decidedly not hordes of people leaving Windows, and if they are, what the hell are they leaving it for?

iOS and Android on mobile, and Linux on servers. This is why there are iOS and Android ports of Microsoft Office, and Hyper-V (and by extension Azure) have first class support for running Linux guests.

[–]DevestatingAttack 0 ポイント1 ポイント  (1子コメント)

The larger point that I was making is that if people are leaving the operating systems, they are not leaving them for significantly more "flexible" choices. does anyone really believe that iOS and Android are more flexible than Windows and Linux?

[–]tidux 0 ポイント1 ポイント  (0子コメント)

Android is Linux. If you have root or the right app, you can dump a full GNU userland in there, even X clients, and there's an X server app with full keyboard and mouse support. It's just that almost nobody does this because Android on devices large enough to use as laptops or desktops is pretty rare compared to Android on phones and 7"-9" tablets.

[–]Arizhel -1 ポイント0 ポイント  (0子コメント)

There are pretty decidedly not hordes of people leaving Windows, and if they are, what the hell are they leaving it for?

Actually, there are. They're leaving it for mobile devices (iPads), and/or for Windows 7 (i.e., they're refusing to "upgrade" and just keeping their old computers).

As for customizability, it becomes a bigger factor when people hate the defaults. Apple device users don't seem to mind the defaults there, so they don't complain about it much. Those that do go to Android, whose defaults they like better, or if they don't, can actually be changed with various apps (there's a bunch of different dialer apps for Android, for instance). GNOME isn't the only DE for Linux; there's tons of them, and Gnome has lost lots of users to KDE, MATE, Cinnamon, etc. over the past few years because people hate Gnome3 so much.

[–]catern -1 ポイント0 ポイント  (1子コメント)

Really. You think Windows has more configurability than GNOME.

It's amazing how people so boldly talk about things that have no idea about. As far as I know, the Windows graphical shell doesn't have an API for extension, nor is it free software.

Where are all these people who hate GNOME so much that they like to praise proprietary software coming from?

[–]Arizhel 3 ポイント4 ポイント  (0子コメント)

nor is it free software.

Gnome being Free software is completely irrelevant with regards to configurability in the real world. You can't seriously expect users to compile their own custom versions of Gnome.

[–]H3g3m0n -1 ポイント0 ポイント  (4子コメント)

Haiku sort of seems exactly like building on another layer.

Personally I would love to see an OS that treats all systems like one big one. Built from the ground up to follow the advances we have seen in the devops community but bring it to the desktop space.

[–]andermetalsh 1 ポイント2 ポイント  (3子コメント)

Personally I would love to see an OS that treats all systems like one big one. Built from the ground up to follow the advances we have seen in the devops community but bring it to the desktop space.

That's Haiku:

http://api.haiku-os.org/

[–]indieinvader -1 ポイント0 ポイント  (2子コメント)

I think maybe you meant DCOS

[–]andermetalsh 0 ポイント1 ポイント  (1子コメント)

Runs on top of Linux. I've seen enough .

[–]indieinvader -1 ポイント0 ポイント  (0子コメント)

Think about it though, if you could implement the Mesos stack as an operating system and implement some kind of durable storage system or service, you'd have implemented a network transparent microkernel.

[–]FunctionPlastic 9 ポイント10 ポイント  (28子コメント)

My hope is that Rust catches on, someone implements a much cooler, easier to develop, and faster-moving kernel with it - another culture is born.

Edit: warning, silly daydreaming I accidentally posted on Reddit

[–]gaggra 9 ポイント10 ポイント  (1子コメント)

It's a shame that a dumb comment about how operating system development needs to be "cooler" and "faster" has been replied to with an even dumber string of comments that by contrast makes the parent comment look insightful.

(Though on the other hand, it would be nice to see more low-level alternatives to C.)

[–]FunctionPlastic 6 ポイント7 ポイント  (0子コメント)

It's a shame that people are interpreting my obviously not serious post this seriously

Well, not really a shame, just kind of nagging

Also, if we're getting serious - it's not about the number of languages, I would much prefer just one better low-level language catching on, and personally the best candidate really is Rust.

[–]Arizhel 4 ポイント5 ポイント  (5子コメント)

The Linux kernel isn't fast-moving enough for you? Exactly which features is it missing that you're dying to have, or aren't being developed fast enough for you?

I haven't seen any kernels that experience development remotely as fast as Linux.

[–]FunctionPlastic 0 ポイント1 ポイント  (4子コメント)

Man, read on, I wasn't being serious.

My point was that a language like Rust allowed for better productivity and would lead to a different, maybe better, code structures.

[–]Arizhel 0 ポイント1 ポイント  (3子コメント)

This is entirely hypothetical and really quite questionable. First of all, you need to consider inertia: millions upon millions of man-hours are already invested in the Linux kernel, written in C. It's a truly enormous software project which has been going on for decades now, and also includes an enormous amount of hardware support (drivers). It's generally considered extremely reliable and also as having the best driver support of any OS. Making an all-new kernel in another language, even if you just do a direct port from C->Rust, would require an immense amount of work in both writing and testing. It's also questionable how the performance would compare; would the Rust version be slower? How good and mature are Rust compilers anyway?

But, if you want to ignore all those real-world considerations and just assume all the kernel devs are jacked up to rewrite the kernel in Rust (after all, a lot of work on the kernel has been thrown out as it was replaced by newer, better things, and a ground-up rewrite isn't really necessary, it can just be ported to the new language and all the mechanisms and APIs preserved), I think that for the kind of people who do kernel programming, using C doesn't seem to be a big problem for them, so it's really questionable how much benefit would be experienced by switching to Rust, or any other language. Once you're familiar with the code conventions used in the kernel (the various macros, for instance, which are frequently used to implement features found in higher-level languages), it's not like you spend lots of time working around the lack of features in C. That's why they put all those macros in there, after all. The kernel is very low-level, and kernel programming is not at all like application programming. Most of your time spent in kernel programming is spent in testing, debugging, figuring out how to deal with timing problems, etc., not in pumping out code. (Some of this depends on whether you're doing driver programming or actual kernel programming; working with actual hardware can be a little tricky, whereas other parts of the kernel (like schedulers) are basically implementations of CS concepts.)

[–]FunctionPlastic 0 ポイント1 ポイント  (2子コメント)

OK let me just clarify something: I am not suggesting that the Linux kernel should switch to Rust, or that we should all just quit using Linux and start working on something else because we have a better language. I realize that is nonsense, and you're responding to me as if you took all my hyperbolic posts quite literally.

However, I will respond to some of your points about how suitable Rust as a language is for these problems. I'm merely defending using Rust as an OS implementation language - which I do believe is reasonable!

Making an all-new kernel in another language, even if you just do a direct port from C->Rust, would require an immense amount of work in both writing and testing.

Yeah, obviously. You wouldn't be doing a direct port, though, because Rust has a different way of solving problems. Some people are already working on kernels in Rust.

It's also questionable how the performance would compare; would the Rust version be slower? How good and mature are Rust compilers anyway?

Rust uses LLVM as a backend and performance parity with C is the goal I believe, which is completely realistic.

Having much stricter guarantees and more information available to the compiler, though, would make room for more optimizations. One of Bjarne's recent articles on C++ demonstrates this point quite well with an example of std::sort being much faster than qsort in some cases, exactly because of additional information.

But, if you want to ignore all those real-world considerations and just assume all the kernel devs are jacked up to rewrite the kernel in Rust

That's not at all what I'm assuming. Read other comments on my thread - I was daydreaming about how different a OS culture centered around Rust could be, and how different would their technical solutions be.

Just like there had been mainstream Lisp-based operating systems in the past, and how universities developed their own operating systems, with different philosophies and solutions. It's more poetic than technical really.

I think that for the kind of people who do kernel programming, using C doesn't seem to be a big problem for them, so it's really questionable how much benefit would be experienced by switching to Rust, or any other language.

Well it wasn't a problem when smart people were using assembly to solve tasks. A new language with better abstractions, similar performance, and more safety - which we can agree is crucial here - would definitely allow them to focus on more important tasks.

Once you're familiar with the code conventions used in the kernel (the various macros, for instance, which are frequently used to implement features found in higher-level languages), it's not like you spend lots of time working around the lack of features in C.

I'm not buying this. It would be extremely inconvenient, if not practically impossible, to make use type classes, higher-ordered types, closures and lambdas, polymorphic structures, the entire concept of ownership and lifetimes that Rust is build around - in C. Those features can definitely be useful in any software project - not all of them at the same time, but if you built the kernel around a language that supported them, you'd surely find use for them.

In the very kernel and drivers, which are quite procedural, you probably wouldn't use all the abstract functional programming features, but there are other technical and theoretical benefits of Rust that you certainly could benefit from.

And of course, the kernel is just a component of the entire operating system. Other components would surely benefit from abstract features.

The point of language is to make such constructs readily available so you can think in terms of them. Sure you can implement them in C but then you're thinking about that and the language will never bend to your need, you'll have to bend your needs for the language.

Also, just to preemptively block a potential objection from your side to this - no, Rust isn't "limited" in performance by these features, and you can always drop down to unsafe code. In fact, incorporating assembly code in Rust is easier because so many problems are solved for you, and although I haven't used it - I hear the C FFI is quite advanced so you've got no issues at that front either.

[–]Arizhel 1 ポイント2 ポイント  (1子コメント)

I realize that is nonsense, and you're responding to me as if you took all my hyperbolic posts quite literally.

No, I realize you're not literally suggesting everyone go this route. This is simply an academic discussion as I see it, and that's how I was treating it, mostly (at least in my most recent response).

But, if you want to ignore all those real-world considerations and just assume all the kernel devs are jacked up to rewrite the kernel in Rust That's not at all what I'm assuming.

You misunderstand me. At that point, I'm making that assumption, for the sake of academic discussion. Sorry if that wasn't more clearly written; I should have phrased it, "Let's ignore all those real-world considerations and assume..."

Well it wasn't a problem when smart people were using assembly to solve tasks.

To be honest, I can't think of a lot of places where people used assembly for a task, then came back later and redid the same task in C. Switching to C (or something else) usually was part of a larger redo. UNIX, for example, has always been written in C, from the very outset. Windows 3 was written in ASM I believe, but when they moved on (95 was C, I think), they didn't just do a rewrite, the entire architecture was changed in a major way, and Win95 was able to do things that Win3 simply couldn't do. Switching to a new language, at that point, wasn't just done because "this language will let us do the same thing better", it was done because "we can do big things that simply aren't technically feasible in ASM because ASM is too hard to work with".

So, it might certainly be possible to do things with Rust which were less feasible in C due to the lesser level of abstraction, but what? When they write Win95, they certainly knew what they wanted to do with it, as far more advanced OSes had already been out for a long time at that point (UNIX, VMS, they were already working on NT at that point IIRC), so it's not like they were blazing new trails. Same goes for NT and XP; these were really just sorta-copies of VMS at the kernel level.

So the question here is, what real benefit stands to be realized with a new language?

and more safety - which we can agree is crucial here - would definitely allow them to focus on more important tasks.

Well one problem I do see here is that Rust is a higher-level language, and as such far less deterministic than C. This alone seems to make it less safe. I have a hard time imagining safety-critical embedded systems switching to such a language. There's a reason these systems eschew high-level languages, and even when they do use C++, they forbid the use of many features such as exception-handling. They even turn off the on-CPU caches on these systems.

And of course, the kernel is just a component of the entire operating system. Other components would surely benefit from abstract features.

This discussion is really only about the kernel AFAIC; other parts of an OS have different needs and restrictions. Kernels are special because they're so low-level and touch the hardware. Who really cares what language a shell interpreter is written in, for instance?

Rust isn't "limited" in performance by these features, and you can always drop down to unsafe code. In fact, incorporating assembly code in Rust is easier

That's good, but really shouldn't be a huge issue. Modern OS kernels don't use much ASM, because it is difficult to program well, and worst of all, it's non-portable. So its use is restricted to only places where it's absolutely necessary (implementing interrupts, for instance). The issue is the rest of the kernel's performance.

[–]FunctionPlastic 0 ポイント1 ポイント  (0子コメント)

So the question here is, what real benefit stands to be realized with a new language?

Well the key problem here is that you seem to be talking about porting Linux from C to Rust - a tremendously laborious task which I can honestly find no justification for - while I'm talking about creating an entirely new operating system, including the kernel, system tooling, the compiler (being rustc and LLVM), and all that.

Now, that's obviously a discussion that touches some totally new questions - mainly the actual design of that system. It'd be difficult to isolate the benefits of the new language, but I can try:

  • More safety. You would be guaranteed to have no bugs of certain classes, like memory leaks, dangling pointers, and all that - in majority of your code. This is extremely beneficial for a new project of this scope and type.
  • Faster development. Rust has many facilities that speed up your development process, like a more advanced type system, better syntax (subjective but I really think it is, especially wrt type annotation), and functional programming elements which allow for much better composition.
  • Better maintainability. Because of Rust's new constructs, a new way of doing things, and support for better abstraction, I believe code clarity would improve, and the language would encourage you to simply think more about the code that you are writing.
  • Tooling support. Many important C tools can be leveraged by Rust projects, such as gdb and Valgrind, but the Rust community will surely develop their own, and since there aren't 20 competing Rust implementations, they will be able to rely on standards and work better together.

If I knew Rust better I could certainly get more specific, but I'm just learning it.

Well one problem I do see here is that Rust is a higher-level language, and as such far less deterministic than C.

The most important Rust innovations are completely static and have nothing to do with the runtime.

C++'s abstractions like virtual methods, exceptions, RTTI, and everything related to inheritance, introduce much more runtime overhead than anything Rust has to offer.

Rust was designed to be a systems language.

This alone seems to make it less safe.

Huh? Python is more safe than C, because it doesn't allow for atrocious bugs that plague C code, which I've already mentioned above.

Rust introduces the concepts of ownership, borrowing, lifetimes, and requires you to be very conscious and explicit with your resource usage - and not just memory, but all types of resources. It also has the C++ concept of RAII if you want it.

I have a hard time imagining safety-critical embedded systems switching to such a language. There's a reason these systems eschew high-level languages, and even when they do use C++, they forbid the use of many features such as exception-handling. They even turn off the on-CPU caches on these systems.

Now you seem to be talking about determinism and real-time guarantees again. I've already replied to those sorts of worries, but I guarantee you that you can also restrict your usage of Rust features, drop down to unsafe code, write asm directly, and it generally has more predictable behavior than C++.

This discussion is really only about the kernel AFAIC;other parts of an OS have different needs and restrictions. Kernels are special because they're so low-level and touch the hardware.

I really meant the OS actually, since that's what users interact with the most - I'd like to see some new ideas on actual design of operating systems, and Rust would just be a component of that.

Who really cares what language a shell interpreter is written in, for instance?

Really? With so many bugs explicitly coming from the shell, and shell being one of the most critical aspects of the OS - I would most definitely prefer it written in a language like Rust!

[–]hobbes_hobbes -2 ポイント-1 ポイント  (13子コメント)

LOL.

[–]FunctionPlastic 0 ポイント1 ポイント  (12子コメント)

Thanks for making me notice, see edit

[–]clofresh -1 ポイント0 ポイント  (5子コメント)

No worries, I share a similar daydream except with Go instead of Rust! Haven't tried Rust yet but I found this cool post where someone writes a hello world kernel using Rust: http://jvns.ca/blog/2014/03/12/the-rust-os-story/

That said, I think the dependency sprawl is more from the userland libraries than the kernel. If Linux had a standard library closer to the OS coupled with a system programming language that matched end users needs, we wouldn't need to have crazy layers upon layers just to print "hello" (as is mentioned in the Rust post)

[–]sinxoveretothex 4 ポイント5 ポイント  (0子コメント)

If Linux had a standard library closer to the OS coupled with a system programming language that matched end users needs

I'm not sure that can be done. I recently watched Daniel Stone's The Real Story Behind Wayland and X and I was amazed at how he described how things that were well adapted when X was started are completely obsolete today and just don't work.

I don't see how coupling librairies and programming language to a kernel would avoid that kind of "badly adapted to problems outside their original problem domain", much less how that kind of integration could work out for something as open-ended as matching end users' needs?

[–]FunctionPlastic 1 ポイント2 ポイント  (3子コメント)

Wow thanks for that link. I remember there existing a Go OS as well, full of mystical references or something searches the internet

Actually those references turned out to be profanities and of course it's cat -v's doing

God damn it

[–]gaggra 2 ポイント3 ポイント  (2子コメント)

...GoFuckYourself, I think it was called? I love those guys.

[–]FunctionPlastic 0 ポイント1 ポイント  (1子コメント)

They're a compete mystery to me. I see their stuff linked from time to time and I can't ever tell whether it's all an obscure joke...

Either way, they're the extreme of what I was referring to when I said culture. Operating systems just give birth to them, and surely also languages, maybe even frameworks. It's an interesting phenomena how tools shape people. Maybe better tools would really lead to better people, but again I'm not actually being very serious.

[–]tidux 1 ポイント2 ポイント  (0子コメント)

They're a compete mystery to me. I see their stuff linked from time to time and I can't ever tell whether it's all an obscure joke...

Considering that Uriel literally killed himself from depression I think they're serious.

[–]tadni 0 ポイント1 ポイント  (0子コメント)

Its not really "from scratch ", but Suckless has a long history of tools being mimimal, bordering the extreme.

[–]traxislyte 37 ポイント38 ポイント  (50子コメント)

The innovation that happens today is basically layering on layers, as the author says. I think Joel Spolsky once blamed it on "JavaSchools", but it's at all levels, not just the devs.

Sysadmins are up to the cloud layer now where it's everything-as-a-service. Instead of "manage a great server", the job of the sysadmin has now become "screw it, manage your server yourself. I gave you a cloud layer to spin up your instance. You figure the rest out."

[–]itscomingtown 44 ポイント45 ポイント  (47子コメント)

Javascript is another example. If you need a high performing javascript engine for doing large and complex calculations, you are using the wrong language. Period. But now I'm being forced to use an ever-more bloated and RAM hungry pile of crap because people are too stupid to use the proper programming language for their software. Javascript is for things like context menus and responsive elements on a web page, not a 3D FPS Doom clone...

[–]gaggra 30 ポイント31 ポイント  (23子コメント)

Give a man a hammer, and every problem starts to look like a nail. This is the problem with a generation of programmers weaned on web development. But it's hard to blame them, when the "modern" web browser is becoming so monstrously powerful that it is slowly replacing the operating system itself. How do you break the cycle?

[–]avita1 27 ポイント28 ポイント  (16子コメント)

Absolutly, just look at the state of desktop programming. One can either:

  • learn objective-c/swift and cocoa and make nice OSX apps or nice iPhone apps
  • learn C#/F# and .NET make nice windows apps or windows phone apps
  • learn android flavored java and make nice android apps
  • learn GTK/Qt/Whatever and make okay desktop apps while doing a lot of backflips to get it build on all platforms.
  • learn web programming and be able to target all the platforms with admittedly lower quality software without said backflips.

I don't like Javascript. In fact, I would prefer almost any of the languages I mentioned above. But every time I try to use another tool, I get frustrated that the number of devices on which I can run whatever I'm writing has effectively shrunk by at least 50%.

If would be nice if Qt was as friendly as javascript. I would love it if a nice UI layer with CLR bindings popped up, and we could write everything in F#. But that probably won't happen. So the best we can do is the web browser (and hey, it's been getting better and better.)

[–]d0x_ 2 ポイント3 ポイント  (9子コメント)

I agree but what about Python? :)

[–]vytah 9 ポイント10 ポイント  (8子コメント)

Sadly, Python isn't doing too well.

/u/avita1 created a mapping from programming languages to software types. I'll make a reverse mapping – from software types to the most commonly used programing languages in each area:

  • webapps – one of the strongest sides of Python, although Node, Ruby, PHP and JVM languages are more popular. I also expect a surge in .Net webapps when .Net starts running on Linux.

  • backend software – usually JVM, .Net, sometimes Go

  • desktop games – C++, C#, sometimes JVM and JS

  • plugin scripting – JS and Lua

  • mobile apps and games – Java, JS, Objective-C

  • embedded development – chiefly C and other lower-level languages

  • software drivers, codecs – C or C++

  • scientific programming – Matlab, R, Python, Julia

  • desktop software – on Windows C#, on OSX Objective-C, cross-platform and Linux programs are written in a variety of languages

  • shell scripts – shell, bash, sometimes Perl

  • command-line tools – anything goes

These cover the vast majority of software you see everyday. In order for Python to succeed, it needs to dominate some of those categories, or at least be one of the best alternatives in them. As it is now, for most kinds of software there is either equal or better option than Python.

While I like Python and I would choose it to make a desktop app or a webapp, other people could choose something else and their choice would be equally valid, if not more justified in some cases.

[–]d0x_ 1 ポイント2 ポイント  (7子コメント)

Awesome post. I've changed my major from sysadmin work to programming. Still debating what language I want to learn on the side. The uni programs have us learning Java, can't say I'm a huge fan. C++ seems like it would be the most useful, I know Matlab programmers are making bank but mathematics are not my strong point. Any recommendations? Python appeals to me for the speed at which one can do more with less code and the cross platform aspect. Mainly looking to learn something that will land me a job opportunity and that will be around for a while.

[–]vytah 6 ポイント7 ポイント  (5子コメント)

Java is still pretty popular, you should have much trouble landing a Java job.

If you are learning, try programming from various perspectives and avoid badly designed technologies.

Languages like (1) Ruby, Lua, C, (2) Haskell, Clojure, Scheme can be a nice add-on that will stimulate you mentally. Out of those, languages from group (1) have an important position in their respective niches, and languages from group (2) are almost ignorable from the market standpoint.

Python, C++, Objective-C, Javascript will be nice too, to a lesser degree. (C++ and Objective-C because it's easier in them to abstract things away and ignore most of the low level stuff, unlike in C.)

I suggest reading (not doing, just reading) a comprehensive tutorial for most of the above, and then picking whatever you want. Make an informed choice, not just because one person on the internet told you so.

But now a person on the internet will tell you that right now you probably don't want to learn the following languages:

Scala, F#, Common Lisp – while nice, leave them alone for now. That's advanced stuff.

R, Matlab, Julia – that's for people who are interested in maths or datamining. Also, R and Matlab suck as languages.

Go is a mixed bag. I don't like it, it feels hastily cobbled together. It's not bad, it's just not good either. Since it's not a very popular language yet, you can skip it.

There's a lot of decent, but not groundbreaking languages with tiny userbase (e.g. D, Kotlin, Ocaml, Object Pascal, Swift, Dart, Vala, Nim, Haxe etc.). I don't think there's a point in learning them unless they happen to fit a narrow niche you are interested in.

Don't learn PHP, it's usually not worth it – PHP devs are usually paid less than others, and the language itself is dreadful.

Leave C# for later, since it's almost the same thing as Java. You'll just reinforce bad habits.

Don't learn VB.NET – most .Net shops use C#, and those two languages have identical features anyway.

As for Perl, unless you need it, ignore it.

[–]jp599 1 ポイント2 ポイント  (0子コメント)

Excellent advice for getting a standard job as a Blub programmer.

[–]Desiderantes 2 ポイント3 ポイント  (2子コメント)

I love how Haskell is considered essential, but Vala and Swift are niche tier. Also no mention of Scheme. Lovely bias.

[–]vytah 1 ポイント2 ポイント  (1子コメント)

Scheme is in the essential group, you missed it.

Vala and Swift aren't groundbreaking and aren't universal. Learning them as a second language after Java would be a waste of time. Besides, it's /r/linux, Swift is not libre enough.

Haskell, while it's not popular for making actual useful stuff, forces you to get rid of many bad habits which you might have accrued while coding imperatively.

Guess what two languages are ranked the highest in "Learning this language improved my ability as a programmer" category on Hammer Principle.

In fact, I recommend the entire site. I should have linked to it earlier.

[–]d0x_ 0 ポイント1 ポイント  (0子コメント)

Awesome comprehensive post I really appreciate the time you put into this and will be referencing it!

[–]iamthem 0 ポイント1 ポイント  (0子コメント)

Here is a flowchart that was making the rounds: http://cdn2.carlcheo.com/wp-content/uploads/2014/12/which-programming-language-should-i-learn-first-infographic.png

It does seem a bit biased towards Python, but that's okay because Python is awesome! I've used Ruby (a lot), C#, C++, C, Java (a lot), Groovy. IMO, Python is by far the simplest language I've seen, in the sense that you can summarize all there is to Python on a cheat sheet. Yet, it's also widely used, especially in scientific fields (the scientific trifecta of numpy, scipy, and pandas is hard to beat). But web apps (Reddit for instance!), cross platform GUIs (Python is Ubuntu's go to language in many cases), 3d games, etc. etc. as well. I see it as a free alternative to MATLAB that can also more realistically make production applications.

[–]fixed_that_for_me 10 ポイント11 ポイント  (5子コメント)

learn web programming and be able to target all the platforms with admittedly lower quality software without said backflips.

If you think that web programming doesn't involve doing backflips due to platform differences, you probably haven't worked on complex web applications.

[–]avita1 8 ポイント9 ポイント  (2子コメント)

If you think that web programming doesn't involve doing backflips due to platform differences, you probably haven't worked on complex web applications.

I have, but "no backflips" is admittedly an oversimplification.

There are fewer backflips. With a website, you deal with CSS quirks. With a compiled application you deal with the intricacies of having a sane build environment accross Linux/OSX/Windows. If you want something that works on phones, you just have to write the same app twice. Period.

My only significant experience is with browser stuff, so maybe I'm wrong. My only point is that it's way easier to write something portable if you're targeting the web.

[–]fixed_that_for_me 2 ポイント3 ポイント  (0子コメント)

There are fewer backflips. With a website, you deal with CSS quirks. With a compiled application you deal with the intricacies of having a sane build environment accross Linux/OSX/Windows.

CSS quirks and crappy API support.

Drag and drop is a good example of this. Ever try to write an application that handles file drag and drop in/out of a web application and supports the big four browsers? Plenty of those APIs are implemented with differing forms of suck across the most recent major versions of said browsers. They even have platform-specific quirks (i.e. Firefox on Windows can and will behave differently than Firefox on Linux.)

There are different backflips. And somewhat fewer than desktop applications. Although given how crippled web applications are compared to desktop applications I'm not that's a good metric. I mean... the hack/feature ratio may end up being about the same.

[–]FrozenCow 0 ポイント1 ポイント  (0子コメント)

The difference I think is with cross platform desktop applications, you have an abstraction that is crossplatform. Once you nailed that abstraction you can be fairly sure it stays stable.

When you're working on CSS you are in a minefield of potential cross browser errors. You cannot abstract from this easily (or rather: I don't know of any library that guards you from this). With changes to CSS you'll have to test and see whether things work correctly on all browsers.

[–]ProdigySim 1 ポイント2 ポイント  (1子コメント)

I wouldn't really compare installing polyfills and writing a few ui-related hacks to having to build completely different frontend apps for android/ios/win/osx.

[–]fixed_that_for_me 0 ポイント1 ポイント  (0子コメント)

I don't do mobile development, so I can't comment on that.

But my point wasn't that the web doesn't abstract away some of the suck. It does. What it doesn't do is reduce the hack/feature ratio. There are fewer hacks needed for a web application not because it's a better environment, but because it's a less capable one.

[–]MrToolBelt 4 ポイント5 ポイント  (0子コメント)

I don't think the cycle is going to be broken. At least not commercially. People are addicted to the insanely fast iteration + easy 'cross platform'-ness of these abstractions.

[–]itscomingtown 8 ポイント9 ポイント  (3子コメント)

I don't know how to break the cycle, but it needs to happen, or pretty soon we will be running an operating system inside and operating system, etc. Ad nauseam. The ONLY innovation that happens today seems to be abstraction of abstractions.

[–]slick8086 8 ポイント9 ポイント  (0子コメント)

pretty soon we will be running an operating system inside and operating system, etc

Already happening. base OS > Chrome > Facebook

[–]Imxset21 4 ポイント5 ポイント  (1子コメント)

That's the thing though. We already are, to an extent. ChromeOS? Firefox OS? Those are things that exist.

[–]itscomingtown 3 ポイント4 ポイント  (0子コメント)

Yep, and they run on your desktop in the guise of a web browser.

[–]Oflameo 1 ポイント2 ポイント  (0子コメント)

My solution is to make Secure Shell a first class interface on the Internet to give people an option to avoid many wasteful interfaces brought by the web.

Joomla and Drupal even have libraries for developing shell sites so I can make it so users can get most of the same content.

[–]utrack 37 ポイント38 ポイント  (2子コメント)

Oh hi! It looked like I'm the only one alive who still wonders why there's so many offline nodejs apps. There's even servers working on top of js server, and devs don't see anything wrong with it...

[–]MrToolBelt 9 ポイント10 ポイント  (1子コメント)

Man, I yell at the sky about this all the time. Typical response is "node is so easy, why use anything else".

[–]Lerc 1 ポイント2 ポイント  (0子コメント)

I have a project with a node component. It's a give and take. I threw it together really quickly, and the rest of the project could not progress until that component was working. So it let me move forward quickly. Now, as I progress, the Node part is the thing that is becoming the most in-need of replacement. I can see things being stuck with Node if they get into production and get iteratively updated because people don't want to break things.

[–]ca178858 4 ポイント5 ポイント  (16子コメント)

In my opinion it'd be ok (or worth the tradeoff) if it was some wonderful language, but JS is hackish and missing lots of basics.

[–]nomoch 0 ポイント1 ポイント  (0子コメント)

If it's a way to get off load most of the computation to the user that it's not too bad. Since we're stuck with shit operating systems use by the majority of people it's not like you have much of a choice anyway. With firefox supporting everything from windows 95 onwards it's one of the easiest ways to support everyone, especially with something like asm.js.

The problem is that so many people are using it on their own servers, which is insane since you have total control over that.

[–]bokabo -2 ポイント-1 ポイント  (1子コメント)

I have a slightly opposing view. The reason Javascript became the omnipresent language it is now is that it was available without trouble. Developers and their bosses learned that they could bypass the OS wars by shoving everything in a browsers and dealing with it that way. I could hire one guy who knows javascript well to make a website work on every platform with far fewer hiccups even if it is less efficient. Sometimes alarmingly so. Or I could hire a team of developers to make my app cross compatable. Meaning I need a guy who knows objective C, and swift. A guy who knows .NET and a guy who knows any other random creation suite someone makes. Economically making "better" software on more platforms is usually not worth the effort. Especially when the only thing the user cares about is does this shit work. I'm a firm believer in the claim that user experience is everything. Elegance be damned. In many ways I think JavaScript shows you why. Less efficient but cheaper to make and upkeep is a trade off most successful business make without hesitation.

[–]itscomingtown 1 ポイント2 ポイント  (0子コメント)

Java was made specifically for cross-OS and cross-architecture development, which for applications it is a FAR FAR FAR supurior tool.

What bothers me most about javascript is that the dumbest fucking people on earth are using it to make everything on their website, down to the loading of text... We have HTML and CSS for websites, javascript is almost never needed for a website, yet fucking retards use it in place of any html of CSS. On some websites, the only html they have is what's required to load their shitty&bloated javashit code.

This bullshit causes their terrible website to use over 10 times the amount of memory and processing time than if they had made a website the right way.

[–]flopgd 2 ポイント3 ポイント  (0子コメント)

level 1 cache is the best cache!

[–]Tacticus 1 ポイント2 ポイント  (0子コメント)

Instead of "manage a great server"

instead of managing a pet i have a few hundred servers i need to deal with.

the job of the sysadmin has now become "screw it, manage your server yourself. I gave you a cloud layer to spin up your instance. You figure the rest out."

The job of the sysadmin has become more to manage the bits they know. while leaving the bits the devs know (actual fucking applications) to them.

And there are still less jobs around.

[–]mgr86 5 ポイント6 ポイント  (3子コメント)

Thirteen years ago also marks the apogee of the dot-com euphoria, where every teenager was a Web programmer

Aw the nostalgia.

[–]h-v-smacker 2 ポイント3 ポイント  (2子コメント)

where every teenager was a Web programmer

Aw the nostalgia.

Have I missed something? I thought this remained true even today...

[–]Decker108 1 ポイント2 ポイント  (0子コメント)

It's called "coming full circle".

As a consultant specialized in saving these newly sprouted companies from drowning in their own accidental complexity, well, the good times are rolling.

[–]mgr86 1 ポイント2 ポイント  (0子コメント)

beats me, but I was just remembering my teenage years in the late 90s where I could right click on a website view its source and do what they were doing. if something seemed a little bit complex well I just had to fiddle with a perl script. It brings me back to my youth. If that is still occurring today thats great too.

[–]mercenary_sysadmin 20 ポイント21 ポイント  (0子コメント)

What the actual fuck?

Kamp starts out lambasting Raymond, then goes on to tell us how he's unhappy with BSD - and the ports tree in particular - which never really embraced the bazaar and is ridiculously more difficult to manage day-to-day than either RHEL derived or Debian derived systems, both of which ARE products of the bazaar.

Don't get me wrong, PHK has done some great code work - in particular, I use Varnish very heavily - but I don't think he's got his head screwed on straight here.

TL;DR Poul-Henning Kamp is confusedly and incoherently ranting about random shit, I want a refund.

[–]Beelzebud 16 ポイント17 ポイント  (19子コメント)

And yet the Bazaar has produced an open source OS that has more people using a Unix-like system than at any point in computing history.

Going by the cathedral/bazaar analogy, what does he think having a regulating body controlling all aspects of development would produce? If he wants that he could always switch to MS or Apple.

[–]gaggra 15 ポイント16 ポイント  (5子コメント)

And yet the Bazaar has produced an open source OS that has more people using a Unix-like system than at any point in computing history.

Firstly, the bazaar we see today is a child of the Unix cathedral. You cannot attribute all success to the bazaar when it would not exist without the structure of the cathedral. Secondly, just because the bazaar has done well does not mean it categorically exceeds the cathedral. A pessimistic view would be to speculate that the bazaar is simply feeding on the corpse of the cathedral - as it has only come up with Unix derivatives - and doesn't have the organization or vision to create a whole new operating system.

[–]Beelzebud 10 ポイント11 ポイント  (0子コメント)

Yeah it's almost like the situation is complex, and that there is room for both styles. But that is reasonable, and doesn't feed into the zealot mindset.

[–]kentrado 2 ポイント3 ポイント  (2子コメント)

as it has only come up with Unix derivatives - and doesn't have the organization or vision to create a whole new operating system.

What? You say that as if Linux is not a whole new operating system at this point.

[–]sinxoveretothex 4 ポイント5 ポイント  (0子コメント)

It is not. You can read Linus' argument (I think that email is part of the Tanenbaum/Torvalds debate) about how Linux made sure to abide by the design of Unix because that was understood and worked well.

I think that is what your parent comment meant: Linux is not a whole new operating system in the sense that it is not a new "design".

[–]DevestatingAttack 2 ポイント3 ポイント  (0子コメント)

If it is, then can we please just mute the fucks that keep calling things "not the Unix way" when we decide to treat audio devices as something other than a text stream, and have applications that do more than one thing

[–]men_cant_be_raped -1 ポイント0 ポイント  (0子コメント)

Firstly, the bazaar we see today is a child of the Unix cathedral.

I'd like to interject for a moment, what you're referring to as "the bazaar" is really "cathedral/bazaar"[...]

[–]gondur 3 ポイント4 ポイント  (0子コメント)

Going by the cathedral/bazaar analogy, what does he think having a regulating body controlling all aspects of development would produce? If he wants that he could always switch to MS or Apple.

Another problem is that some people believe we lost the bazaar way... and our miseries are due to the introduction of too many centralized mini-cathedrals into our ecosystem, see Molnar's opinion:"Desktop Linux distributions are trying to "own" 20 thousand application packages consisting of over a billion lines of code and have created parallel, mostly closed ecosystems around them.[...] They are centrally planned, hierarchical organizations [cathedral] instead of distributed, democratic free societies [bazaar]." (italic comment from me)

(And, no telling people they can "switch" is not solving our problems.)

[–]mercenary_sysadmin 11 ポイント12 ポイント  (4子コメント)

He's extremely confused and incoherent about this. Effectively, BSD still is the cathedral - the entire OS, not just the kernel, is managed by a regulatory body - and yet almost every actual complaint he outlines in this screed is a complaint against BSD's ports tree, which IS a giant pain in the ass to manage compared to... well, modern package management on either RHEL-derived or Debian-derived systems. Products of the bazaar.

[–]gondur 3 ポイント4 ポイント  (0子コメント)

He's extremely confused and incoherent about this. Effectively, BSD still is the cathedral -

He talks about a platform, similar a market place, a infrastructure which is centrally maintained (cleaned, supported with electrical power, water, safety, constraints etc) ...but what happens on top of this infrastructure is the wild, decentralized, unregulated "bazaar".

[–]andermetalsh -1 ポイント0 ポイント  (2子コメント)

BSD port's tree

Not needed on OpenBSD. At all.

[–]mercenary_sysadmin 2 ポイント3 ポイント  (0子コメント)

What's your point? It's not necessarily needed on FreeBSD, at all, either. The reason I mention it is because it's explicitly what PHK was bitching about.

[–]t-bass 0 ポイント1 ポイント  (0子コメント)

Or FreeBSD.

[–]cp5184 5 ポイント6 ポイント  (3子コメント)

And yet the Bazaar has produced an open source OS that has more people using a Unix-like system than at any point in computing history.

Apple OS X?

[–]Decker108 4 ポイント5 ポイント  (2子コメント)

Haha, I was going to say Android OS :)

The fact is that the most successful Unix-like OS's of today are in fact not the shining paragons of bazaar-style development and contribution. They're more of... what's the word again... cathedrals!

[–]Beelzebud 0 ポイント1 ポイント  (1子コメント)

And yet Linux still runs more servers and super computers than any of the "cathedral" systems.

[–]gaggra 5 ポイント6 ポイント  (0子コメント)

Yes, but all that enterprise deployment is enabled by large, cathedral-esque companies like Red Hat and Canonical.

[–]nomoch -2 ポイント-1 ポイント  (2子コメント)

what does he think having a regulating body controlling all aspects of development would produce?

Ubuntu.

When something goes wrong, it goes wrong disastrously.

[–]Beelzebud 12 ポイント13 ポイント  (1子コメント)

Anyone who considers Ubuntu a "disaster" isn't worth listening to about anything.

[–]nomoch -2 ポイント-1 ポイント  (0子コメント)

Amazon lens.

[–]PeterBrett 12 ポイント13 ポイント  (5子コメント)

Are you serious? Yet another poorly-veiled protracted whinge about Autoconf?

[–]chriscowley 31 ポイント32 ポイント  (4子コメント)

whinge about Autoconf

Autoconf thoroughly deserves every single winge

[–]PeterBrett -5 ポイント-4 ポイント  (3子コメント)

whinge about Autoconf

Autoconf thoroughly deserves every single winge

Poor workman, tools, etc.

[–]gaggra 7 ポイント8 ポイント  (0子コメント)

PHP, double-clawed hammer, etc.

Poor workmen exist, and poor tools exist.

[–]chriscowley 0 ポイント1 ポイント  (1子コメント)

I am happy to admit that is quite likely :-)

[–]PeterBrett 0 ポイント1 ポイント  (0子コメント)

I'll be honest: there is a quite a lot of learning - and time - required in order to understand Autotools well enough to get good results with them.

However, I've found the documentation to be really rather good (for example, the explanation of how to write portable shell script is actually incredibly useful) and once I'd got my head around it, writing new macros and sane, readable, maintainable build scripts became quite straightforward. Overall, I've found Autotools to be more reliable and to have provided better, more consistent results than any alternative I've come across yet (at least, for building C and C++ programs).

The problem is, of course, that few people have the patience and/or can take the time to sit down and develop the required expertise. But as someone who has used a variety of build tools in a variety of professional and amateur contexts, I still think that Autotools is genuinely one of the best build tool suites available.

[–]sotonohito 1 ポイント2 ポイント  (1子コメント)

It is for this reason that Vernor Vinge, who is not only an SF writer but also a professor of computer science, had the profession of Programmer Archaeologist being an important thing in his distant future setting.

I can seriously see it happening. Storage is getting cheaper and cheaper, there's no real reason to ever throw anything away, give it even another 100 years and we'll have an environment where being skilled at thrashing through the archives to find solutions to problems may be more efficient than trying to write the solution yourself.

[–]gondur 1 ポイント2 ポイント  (0子コメント)

It is for this reason that Vernor Vinge, who is not only an SF writer but also a professor of computer science, had the profession of Programmer Archaeologist being an important thing in his distant future setting.

it's already

[–]FunctionPlastic 1 ポイント2 ポイント  (3子コメント)

but even then there is no escaping that as IT professionals they mostly sucked because of their lack of ballast.

What does this mean?

[–]ventomareiro 0 ポイント1 ポイント  (1子コメント)

Ballast is what makes a ship keep a stable course while at sea.

[–]FunctionPlastic 1 ポイント2 ポイント  (0子コメント)

I know but what is he trying to say in that sentence? I probably should've included context, please search for it

[–]EatMoreCrisps 0 ポイント1 ポイント  (0子コメント)

The typical lack of master craftsman IT professionals in any given project to learn from.

[–]it_is_my_fault 2 ポイント3 ポイント  (1子コメント)

Well, that was a pile of crap essay. Maybe a couple undigested kernels of truth, but mostly just a weird view of the current environment.

[–]PoisonRain 0 ポイント1 ポイント  (0子コメント)

That was an interesting point of view, but there was nothing approaching a solution presented. If that's the way things are, as far as I can see the only solution is to rewrite things from scratch. And that's incredibly unlikely to work.

[–]jensreuterberg 0 ポイント1 ポイント  (0子コメント)

Yay! The complexity of a real environment distilled into a simplified example, used by another person to criticize the reality based on the simplified example! Trying to figure out something that was under the absolute control of one, with the effect of being that persons total domain and responsibility and I can't think of one real world example over the complexity of a piece of art and even THAT tended historically be the work of several people and often handling sections with a somewhat loose control upwards.

[–]regeya -1 ポイント0 ポイント  (0子コメント)

So...bad software didn't exist before the popularity of Linux?

LOL

[–]stoneage7 0 ポイント1 ポイント  (14子コメント)

Here is one example of an ironic piece of waste: Sam Leffler's graphics/libtiff is one of the 122 packages on the road to www/firefox, yet the resulting Firefox browser does not render TIFF images.

I'm not a programmer but what's the problem here? That runtimes are a thing that exists?

[–]bushel 17 ポイント18 ポイント  (13子コメント)

Requires libtiff. Does not actually use libtiff.

This is an example of waste.

[–]flying-sheep 10 ポイント11 ポイント  (0子コメント)

blame GTK+, because that’s the thing requiring libtiff with firefox requiring GTK+

[–]iheartrms 3 ポイント4 ポイント  (11子コメント)

A library he pulled in probably used libtiff while he doesn't use that particular functionality in that library. Not a big deal IMHO but if he has some idea to fix it I'd like to hear it. The essay was all whining about relatively small stuff with no solutions while disregarding all of the great things this software ecosystem have us which we didn't have before the bazaar.

[–]8fingerlouie 2 ポイント3 ポイント  (10子コメント)

I would assume that PHK certainly has the skills to fix these problems, just not enough hours of life to do it. He has done great work on FreeBSD since forever, written the GEOM disk layer and encryption, sponsored by DARPA.

Besides, FreeBSD itself (excluding ports) is run by a committee, and the quality of the "distribution" is IMO much better than your average linux distribution.

http://people.freebsd.org/~phk/

[–]iheartrms 0 ポイント1 ポイント  (9子コメント)

This really just seems like more of the old BSD vs GPL axe grinding. Fortunately it has never amounted to anything and Linux continues to dominate the UN*X space in just about any way that really matters.

[–]gruehunter 4 ポイント5 ポイント  (4子コメント)

This has nothing whatsoever to do with weak vs strong copylefting, and everything to do with hacking versus engineering.

[–]iheartrms 0 ポイント1 ポイント  (3子コメント)

So he's actually complaining that FreeBSD is hacked and not engineered?

[–]Marzius 1 ポイント2 ポイント  (2子コメント)

The reverse actually.

[–]iheartrms 0 ポイント1 ポイント  (1子コメント)

He's complaining that it is engineered and not hacked? I'm confused.

[–]sinxoveretothex 1 ポイント2 ポイント  (0子コメント)

He's complaining that he has to deal with software that is not engineered and is more or less directly pointing at the ports tree ("Linux software" if you will) while saying that.

[–]8fingerlouie 3 ポイント4 ポイント  (0子コメント)

Linux is also designed by one man. Granted, Linus doesn't design all the features, nor does he provide a roadmap, but he is somewhat (if not very) critical of what he accepts.

What PHK is arguing against is when you just use whatever tool you have available, instead of actually sitting down and thinking about where this would fit best. 90% of the people using autoconf doesn't have a clue what the resulting script ends up doing.

[–]Jaymuhz 5 ポイント6 ポイント  (2子コメント)

But he was criticizing the state of FreeBSD...

[–]mioelnir 1 ポイント2 ポイント  (0子コメント)

But he was criticizing the state of FreeBSD...

What gives you that idea? That he uses the ports tree as example material? Go ahead and build something like the ports tree from all the package maintainer's Makefiles and vendor patches etc for both RHEL or Debian or anything else out there. You really think it looks significantly better?
The fact that most Linux distros do not expose that layer to their users does not mean it is significantly better or worse there under the hood.

What he does criticize is that a lot of stuff in our infrastructure needs a proper cleanup. Some rethinking. Some cut off tails.

[–]mercenary_sysadmin -3 ポイント-2 ポイント  (0子コメント)

Well, sorta, except he was explicitly blasting Raymond and the Bazaar by pointing to examples of difficulty in dealing with his own cathedral. It was pretty incoherent.