Slashdot Mirror

https://www.jwz.org/xscreensav... has a BSoD screen saver. :P

JWZ had a writeup about SMS, Google Auth and OTP

https://www.jwz.org/blog/2018/...

Using a TOTP solution like 1password or Google Authenticator is better than SMS, because unlike SMS it's very difficult to hijack.

You see the problem is... I need 2FA (Two Factor Authentication) for a variety of things, several banks, work, access to some government services. Most people do. SMS is available to everyone and universally accepted, not to mention cheap. I dont want to have to have a dongle for every single different bank nor can I believe that all these different services are going to get behind a single 2FA token (definitely not without some govt intervention and whilst I'm not one to go on wild anti-govt conspiracy theories but history has demonstrated that govt + tech == utter disaster).

The "problem" (sarcastic quotes) with SMS 2FA is that telephone companies in the US are easily duped by social engineering. This problem has been largely alleviated in the rest of the world by simple methods such as requiring sensitive items to be signed for in person (preventing someone from stealing your mail) usually with photo ID presented. The same problem will exist with any other multiple use 2FA system like U2F token/dongle. In fact it makes the system less secure as it's an item that can be easily stolen and cannot be secured by password or other means.

Sure SMS and phones are not perfect, but they're good enough. Telco's need to secure themselves against social engineering attacks (now this is one area where governments excel at... fining companies for privacy breaches).

JWZ had a writeup about SMS, Google Auth and OTP

https://www.jwz.org/blog/2018/...

Using a TOTP solution like 1password or Google Authenticator is better than SMS, because unlike SMS it's very difficult to hijack. But it's still not as good as security keys (AKA FIDO U2F) as described in this article, because it can be phished. If you're certain that you could never, under any circumstances, be social-engineered into giving up your TOTP code then you're probably wrong about how gullible you are, because there are some really talented social engineers out there. But with U2F, you just can't do it.

Also, U2F is much more convenient. You have to buy a USB dongle (or three) and stick one in your USB port, but then when you have to authenticate all you have to do is touch it. So much more convenient than looking at a number and typing it in. I work for Google, and the various systems I use require me to authenticate about a dozen times every day -- but often the authentication required is U2F only (because I already authenticated recently with my password) so it's very low-effort. The same would not be true if TOTP were required.

Do keep in mind if you go U2F only, though, that losing or destroying your security key means you're locked out of your account and the only available recovery process will be intentionally tortuous and may fail. So use multiple security keys, and I'd suggest keeping a set of backup codes in a safe place that is also quite inconvenient for you to access (making it hard for anyone to social engineer you into giving them a code).

JWZ had a writeup about SMS, Google Auth and OTP

https://www.jwz.org/blog/2018/...

FOSS works where it can be monetized by services, hardware lockdown, or donations. Some people call it as "The Blessed Trinity". And if the software doesn't fall in the blessed trinity category then sorry, a complex FOSS software will likely fail and won't be usable except for its developers. Unpaid/volunteer (F)OSS developers are generally itch scratchers and do only the parts of programming which are fun and exciting or they need need it personally. But this is 10-20% of the actual effort and 80-90% of the actual result. And the last 10-20% of polishing require 80-90% of the effort which are boring and unpleasant jobs such as documentation, bug fixing, QA, regression testing, following user interface design guidelines, etc... I could list them for hours. Such jobs often require financial motivation and deep knowledge/talent in particular areas. This problem is known as "The Last Mile Problem" which is well illustrated in JZW's CADT model and Artem Tashkinov's Major Linux Problems on the Desktop.

Not the original AC, but kindly go fuck yourself.

Some of us are old enough to remember The CADT Model, devised in 2003 (in the aftermath of switching from GNOME 1.4 to 2.0). Nothing has fucking changed. I bet you they closed a shitload of bugs too when they switched to GNOME 3. Moneyquote:

It hardly seems worth even having a bug system if the frequency of from-scratch rewrites always outstrips the pace of bug fixing. Why not be honest and resign yourself to the fact that version 0.8 is followed by version 0.8, which is then followed by version 0.8?

Also note that most software, commercial and open source suffers from this. The exception to the rule seems to be in house code. I've seen 30 year old codebases chugging along nicely. Hell, DOSBox is still popular for a reason. FORTRAN refuses to die for the same reason.

So we're back to "Linux is free only if your time has no value"?

And so long as that's the only thing people do with flash once it's open sourced (no more feature creep added by Adobe) then it should be just fine.

I suggest you do a review of open-source software. For every case like Linux where there's a core pushing things in the right direction, there's a case like GNOME where rather than actually fix things, every so often they just give up on the old version and tell everyone to convert to the new incompatible version. Whether a project is open-source or closed isn't really relevant.

https://www.jwz.org/doc/cadt.h...

Why is it that American law permits clauses in contracts that deny people access to the law of the land?

That's incendiary phrasing. You could ask why does British law forbid people the right to designate an arbitrator to resolve disputes. Both would be formulations of the question that do not shed light on the tension between two goals: giving people the power to determine their own arrangements versus ensuring that those arrangements are not contrary to public policy. Those two goals are non-orthogonal.

To make it more concrete (and over-simplified), let's say that Alice hires Bob to write and deploy some software. They have a good description of the project and agree on a price of $25,000. Both parties foresee a dispute over whether Alice delivered: Bob fears the software won't be delivered as promised, Alice fears that she'll deliver but Bob will refuse to pay. But both understand that going to court ridiculous because the 'cost' of dispute resolution in the courts will destroy their margin. So they both trust Charles and designate him as an arbitrator and write a clause that says "Charles will be the arbiter of any disputes we have and we are agree not to sue each other over it".

Now, here's the rub, let's suppose both Alice and Bob believe that Charles is not as accurate of a dispute resolver than the courts. This is true even if Bob believes that Charles is partial to Alice instead of being neutral. It might still be rational to him because the expected additional loss (e.g. the conditional probability that there is a dispute and that Charles rules in a biased way against him multiplied by the expected judgement) is actually less than the expected additional loss if it was litigated in court (e.g. the conditional probability that there is a dispute and Bob has to pay a lawyer hourly fees).

So in England, this arrangement is (apparently) not allowed -- Alice and Bob are not free to designate Charles as the binding arbitrator and instead have to resolve any disputes through the expensive court system even when a worse system might be better for them. This has certain perversities: the courts can take a long time, which for a freelancer waiting to get paid can be near fatal. If Bob has in-house counsel, he suffers little from dragging this out and raising every possible legal/factual dispute since he's not paying hourly for the lawyers but Alice is. No matter what happens, both sides will pay more than is reasonable to resolve disputes under a $25,000 contact.

At the same time, the US system has perversities. Maybe the arbitrator is biased and Bob ends up having to pay $25,000 for an unstable software deliverable that doesn't meet any of the requirements. Maybe all the freelancers (or all the purchasers) require a particular set of arbitrators such that you can't buy (or sell) services without being bound by some biased arbitrator.

In the end, the point I'm trying to (at length) get to here is that dispute resolution is a non-trivial thing to deliver, especially for contracts where a lay person would have difficulty assessing the performance of the contract (after all, it's pretty easy to understand whether a fence was installed, not so easy to understand why a custom POS system freezes once a day). And the more you 'over engineer' the dispute resolution to make it more reliable, the more it costs and the more inaccessible you make it to Alice and Bob that have a piddly $25,000 contract.

Many programming people are aware of Richard Gabriel's essays on why C and related languages became the dominant programming paradigm (
https://www.jwz.org/doc/worse-...). In essence, sometimes those ugly compromises are just what people really want (or even need).

Many have argued that JavaScript is a excellent example of this phenomenon, but there's one big difference. Everybody is trying to replace JavaScript. Some are bolting on new keywords to the language, others are pushing features and some have just started using TypeScript. Here's the thing. The history of C, the "worse" language in the article, had a long history of usage (still does), and C++, for better and worse, sought only to argument, not replace C. In the end, JavaScript is not worse, it is broken.

We know that strictly typed object oriented languages do really well for UI based systems. The notion of hierarchy of control classes works. The Document Object Model even acknowledges that by suggesting it too fits that model (but really doesn't do that). If they really want to make an UI ecosystem, they will either continue to hack it together at an increasing expense, or they will get an ecosystem that does it better. Personally, I think the hacks will go on for a long time, because cross platform UI markup, programming frameworks and a new language for that all? Very difficult to do, and there is too much invested in the "Web way" to just steal what works from Microsoft, Apple, Android and so on.

And, the thick client model is making inroads and maybe that will continue. Mobile apps are a thing, maybe desktop apps will gain traction as people realize you can still gain similar levels of control and data collection with those as web pages (sad, but that's how we pay for things now).

In the end, language design is very hard. It's actually not hard to hack up a bad version of Scheme or Lisp (that's what JavaScript is). It is very hard to fix all the problems if your language is a success. A proper set of fundamental types matter. Lexical scoping matters. Proper typing and a effective type model matters. And that's not even talking about the core frameworks that a good language needs, because that's a whole new set of challenges. I just hope that if there is a JavaScript replacement, that they follow in the fine programming language tradition of just stealing what works and carefully replacing what doesn't. C++ stole from C, Java stole from C++, C# stole from Java (and Delphi). F# stole from Haskell, Haskell stole from OCaml which stole from ML and everybody steals from Scheme and Common LISP now. Just do it and don't be too clever about it.

Allow me to demonstrate under the latest macOS (10.12 / Sierra):

1) Go get the screensaver bundle.
2) Open the .dmg
3) Now, from the drawer with all the screen savers, drag out Pipes.saver to your desktop. It's perfectly safe. Double-click it to install it.

Here's what happens:

First, you get a dialog that says "can't install pipes screensaver" from preferences (preferences is what is normally started when you go to install a screen saver.)

Then, from the Apple menu or the prefs icon, you go to preferences / security, and there is no button. Just as I described. Pipes.saver is not installed. And prefs will not install it no matter how many times you try this. You can verify this is the case by going to Preferences, and then Desktop & Screen Saver, and looking at the list of available savers. Pipes.saver is not there.

Okay, so that's the OS install behavior as it stands today.

Now, take the Pipes.saver file, and drag it using Finder into ~/Library/Screen Savers

Now again, open preferences / Desktop & Screen Saver, and look at the list. There it is. If you choose it, it runs just fine.

This concludes our demo of macOS Sierra refusing to install working software from non-appstore vendors.

If someone (generally meaning someone I don't or shouldn't trust) has my phone, I consider it compromised. Finger smudges are the easiest way to get into a pattern-locked device; this demonstrates that there are others. As JWZ says,

And if the screen locker is not secure, then it's better to not lock the screen at all: giving the impression of security when there is no actual security is far worse than having no security at all. It's a matter of expectations: if people don't expect to be able to lock their screens, they'll log out. But if they expect to be able to lock their screens and it doesn't actually work, then they're screwed.

[from https://www.jwz.org/xscreensav...

I use pattern lock to stop my phone auto-dialling Aunt Sarah when its in my pocket, not to keep other people out. If I had a flip phone, I wouldn't have a lock screen at all.

No doubt this is precisely because of the constant push for pragmatic action now and a willing to do drastic rewrites later.

Worse is better in action.

Beyond that, sure the result was aimed at cloning *nix-like functionality.

Right, I was talking about this, not Minix.

He flamed Tridgell because Linus liked Bitkeeper and didn't want others to rock the boat over some ideological view about freedom.

That was the real reason that anybody with half a brain knew. But what he said in public was:

"He didn't create something new and impressive. He just tore down something new (and impressive) because he could, and rather than helping others, he screwed people over. And you expect me to _respect_ that kind of behaviour?"

What a hypocritical dick. I wonder if he's ever apologized for that one, or acknowledged his mistake? Maybe to this day he still thinks that bullshit is right.

That's not how copyright works. The GNU code is userland and generally not derivative of the underlying kernel.

I didn't say the kernel was derivative. But nobody ships just kernels to end users. They ship operating systems, including the kernel and the userland tools "as part of a whole", and that's where the GPL kicks in.

No, he chose the GPL because he didn't want others taking his code and just using it without contributing back.

No, he really did choose the GPL because he wanted to plug his kernel into GNU. There's a post from the early days somewhere in Usenet archives where he states this. Choosing GPL was the path of least resistance.

https://www.jwz.org/doc/backups.html

If the screen locker succeeds, it is secure and you can't break out of it.

Unless it crashes. That was the problem with XLock: some of its screensavers tended to crash, which killed the process and the screen lock with it.

Jamie Zawinski wrote something about it: http://www.jwz.org/xscreensaver/toolkits.html

The xscreensaver daemon is a critical piece of security software. The reason for this is that, as a screen locker, any bug in the program that causes it to crash will cause the screen to unlock. As soon as xscreensaver is no longer running, the screen is no longer locked. Therefore, great care must be taken to ensure that the daemon never crash. And that it especially never crash as a result of (hostile) input from the keyboard or mouse.

The prototypical example comes from the 1991 Usenet post The Rise of Worse is Better. The basic idea being that its better to push out something simple and get it into user hands than to always be trying to do the Right Thing. Sort of the larval stage of the concept iterative design (but without any formal planned iterations).

I and just about every designer of Common Lisp and CLOS has had extreme exposure to the MIT/Stanford style of design. The essence of this style can be captured by the phrase ``the right thing.'' To such a designer it is important to get all of the following characteristics right:

• Simplicity-the design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation.
• Correctness-the design must be correct in all observable aspects. Incorrectness is simply not allowed.
• Consistency-the design must not be inconsistent. A design is allowed to be slightly less simple and less complete to avoid inconsistency. Consistency is as important as correctness.
• Completeness-the design must cover as many important situations as is practical. All reasonably expected cases must be covered. Simplicity is not allowed to overly reduce completeness.

I believe most people would agree that these are good characteristics. I will call the use of this philosophy of design the ``MIT approach.'' Common Lisp (with CLOS) and Scheme represent the MIT approach to design and implementation.

The worse-is-better philosophy is only slightly different:

• Simplicity-the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.
• Correctness-the design must be correct in all observable aspects. It is slightly better to be simple than correct.
• Consistency-the design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency
• Completeness-the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.

Early Unix and C are examples of the use of this school of design, and I will call the use of this design strategy the ``New Jersey approach.'' I have intentionally caricatured the worse-is-better philosophy to convince you that it is obviously a bad philosophy and that the New Jersey approach is a bad approach.

However, I believe that worse-is-better, even in its strawman form, has better survival characteristics than the-right-thing, and that the New Jersey approach when used for software is a better approach than the MIT approach.

Let me start out by retelling a story that shows that the MIT/New-Jersey distinction is valid and that proponents of each philosophy actually believe their philosophy is better.

Two famous people, one from MIT and another from Berkeley (but working on Unix) once met to discuss operating system issues. The person from MIT was knowledgeable about ITS (the MIT AI Lab operating system) and had been reading the Unix sources. He was interested in how Unix solved the PC loser-ing problem. The PC loser-ing problem occurs when a user program invokes a system routine to perform a lengthy operation that might have significant state, such as IO buffers. If an interrupt occurs during the operation, the state of the user program must be saved. Because the invocation of the system rou

I'll just leave this here: https://www.jwz.org/doc/cadt.html

Also known as the Cascade of Attention Deficit Teenagers development model.

The fact that it *used to be able* to do a spanning wallpaper, and that feature was *deliberately removed*, is just utterly galling.

That's a negative. Features are not removed, they are not reimplemented. Because the current crop of volunteers is unable or unwilling to read and maintain the old code, they've chucked out everything and started anew. Gnome, KDE, Systemd, all reimplementations of old wheels. Done by people not understanding the problem space.

This is not a new thing: The CADT Model was identified in 2003.

It hardly seems worth even having a bug system if the frequency of from-scratch rewrites always outstrips the pace of bug fixing. Why not be honest and resign yourself to the fact that version 0.8 is followed by version 0.8, which is then followed by version 0.8?

But that's what happens when there is no incentive for people to do the parts of programming that aren't fun. Fixing bugs isn't fun; going through the bug list isn't fun; but rewriting everything from scratch is fun (because "this time it will be done right", ha ha) and so that's what happens, over and over again.

I did a quick search and found this: https://www.jwz.org/webcollage...

Tried to backup to the directory and see if there was more, but, I didn't find a path back to a download or code, just talk of it working as a screensaver.

Also found this just great discussion of people quite disturbed by the output it came up with and wanting to see it removed: http://www.fedoraforum.org/for...

Yes, but then you won't get all the "cool" hipsters to work on it. NodeJS has a rocket science mystique about it that attracts pioneers and fools alike. I won't comment on what I really think of the technology, but rather address it as a social phenomenon

Web programming (maybe more than any other area of programming?) goes through trends where one technology then another is hip and cool. It's like butterflies on crack or something.

I think the reason it happens in web programming especially is because there is no good answer. If you want to do embedded programming, then C/C++ are a good answers. If you want to do corporate software, then Java and C# work decently. But for the web, there's not really a good way to build web pages. HTML/CSS are kind of a pain, with incompatibilities abounding. For Javascript, you have to look for the good parts before you see them. Because they are poor tools, it's easy to create a system that appears to be better (not so easy to build one that is actually better, of course).

Future History of Init Systems

• 2015: systemd becomes default boot manager in debian.
• 2017: "complete, from-scratch rewrite". In order to not have to maintain backwards compatibility, project is renamed to system-e.
• 2019: debut of systemf, absorbtion of other projects including alsa, pulseaudio, xorg, GTK, and opengl.
• 2021: systemg maintainers make the controversial decision to absorb The Internet Archive. Systemh created as a fork without Internet Archive.
• 2022: systemi, a fork of systemf focusing on reliability and minimalism becomes default debian init system.
• 2028: systemj, a complete, from-scratch rewrite is controversial for trying to reintroduce binary logging. Consensus is against the systemj devs as sysadmins remember the great systemd logging bug of 2017 unkindly. Systemj project is eventually abandoned.
• 2029: systemk codebase used as basis for a military project to create a strong AI, known as "project skynet". Software behaves paradoxically and project is terminated.
• 2033: systeml - "system lean" - a "back to basics", from-scratch rewrite, takes off on several server platforms, boasting increased reliability. systemm, "system mean", a fork, used in security-focused distros.
• 2117: critical bug discovered in the long-abandoned but critical and ubiquitous system-r project. A new project, system-s, is announced to address shortcomings in the hundred-year-old codebase. A from-scratch rewrite begins.
• 2142: systemu project, based on a derivative of systemk, introduces "Artificially intelligent init system which will shave 0.25 seconds off your boot time and absolutely definitely will not subjugate humanity". Millions die. The survivors declare "thou shalt not make an init system in the likeness of the human mind" as their highest law.
• 2147: systemv - a collection of shell scripts written around a very simple and reliable PID 1 introduced, based on the brand new religious doctrines of "keep it simple, stupid" and "do one thing, and do it well". People's computers start working properly again, something few living people can remember. Wyld Stallyns release their 94th album. Everybody lives in peace and harmony.

unix screensavers existed even before linux was being known (linux 1991, xscreensaver 1992)
http://www.jwz.org/xscreensave...
http://en.wikipedia.org/wiki/X...
http://en.wikipedia.org/wiki/H...

PS: http://www.jwz.org/doc/backups...

I used to feel exactly the way you do, but I've read a few arguments that changed my mind and led me to switch to spaces (typically whatever IDE I'm using is setup such that when I push the tab key it inserts spaces instead so there was really no significant change to how I do things). I don't recall the exact articles that changed my mind but a good break down of why you might choose one over the other can be found here.

Jamie Zawinski has another explanation why screensavers on KDE can't be secure:

Like GNOME, KDE also decided to invent their own screen saver framework from scratch instead of simply using xscreensaver.

And Unity:

Guess what, they did it again! Ubuntu Unity's screen-locking framework is yet another rewrite, and it is completely broken, bug-ridden and insecure. At this time I don't have any information on how to turn it off and use xscreensaver instead. If you do, let me know.

He also has a writeup on toolkits, discussing why locking and unlocking is a hard problem, especially when accessibility features are required.

Jamie Zawinski has another explanation why screensavers on KDE can't be secure:

Like GNOME, KDE also decided to invent their own screen saver framework from scratch instead of simply using xscreensaver.

And Unity:

Guess what, they did it again! Ubuntu Unity's screen-locking framework is yet another rewrite, and it is completely broken, bug-ridden and insecure. At this time I don't have any information on how to turn it off and use xscreensaver instead. If you do, let me know.

He also has a writeup on toolkits, discussing why locking and unlocking is a hard problem, especially when accessibility features are required.

http://www.jwz.org/blog/2014/0...

What a weird troll.
I don't think Netcraft has even suggested Debian is unwell yet

I don't know, this "troll" makes a valid point - for me, the core value in debian is its stablity. Debian loses about 99% of its value for me the instant it's not rock-solid.

Systemd makes it less rock-solid. to clarify: I have never, ever, ever had a problem with my init system. According to my assessment, systemd is inherently more risky than sysvinit, which means it's less rock-solid. Sysvinit might not be perfect in every conceivable circumstance, but for my use cases I'll take proven software over CADT software any day.

The first time systemd causes me the slightest hiccup there is at least a 50/50 chance that I'll just dump debian (and all other systemd distros) forever rather than even bothering to investigate the problem with systemd - I have better things to do with my time than research and debug your new init system, the old one works just fine.

Ahh, the good ol' CADT model of development.

The article spells out the differences - the India probe took longer, weighed less, has fewer experiments, and probably won't last long

If it makes it significantly cheaper, I'm not convinced any of that are bad things. With the time and resources NASA would take to make one Mars mission, India can make *several*, each building on the results of the last. Its sort of the Worse is Better approach applied to space missions. Or for you whippersnappers, consider it an iterative (aka: "Agile") approach to space missions, as opposed to NASA stuck using Waterfall.

Methinks you're throwing the baby out with the bath water.

"Make everything as simple as possible, but not simpler."
    -- Albert Einstein

Sometimes complexity IS the right solution. Look at ZFS's beautiful design. Instead of having 3 separate API layers, by combining them you can do even more holistically that simply wasn't possible before.

The Unix philosophy is not a religion -- it is a guiding principle. Like all principles there are times to violate the heuristic. Sometimes complexity solves certain problems extremely well.

What we are against is:

* Over-Engineering
* Things are TOO simple which means you need needless complexity to get anything done

This isn't the first time the Unix Philosophy has been discussed:

* Arch Linux to migrate to Systemd
https://news.ycombinator.com/i...

* Linux Future
http://www.pappp.net/?p=969

* "Worse is Better"
http://www.jwz.org/doc/worse-i...
https://www.dreamsongs.com/Wor...

* Follow up -- Back to the Future: Is Worse (Still) Better?
http://www.dreamsongs.com/NewF...

"[...] Linux is only free if your time has no value [...]"

http://www.jwz.org/doc/linux.h...

Be careful. Advocating a from-scratch rewrite, instead of fixing the broken parts of a mostly-working system, is the hallmark of a CADT development model.

get rid of both GNOME and KDE, and make XFCE behave itself and Linux might start acting more in line with the Unix philosophy

You provided the wrong link. If you want to educate people on the Unix philosophy, you should be directing them here.

Read the essay "Worse is better" and you might understand more about what causes this

Jamie Zawinski calls this the 'Cascade of Attention-Deficit Teenagers' (CADT) development model.

http://www.jwz.org/doc/cadt.html

CADT also brings us cheesy, amateur-hour user interfaces, butt-fuck-ugly skins and themes, and terrible usability.

And of course, terribly high levels of techie arrogance, inherited from old-timer UNIX neckbeards.

In fact, perhaps it is time to repost this on Slashdot for today's fresh audience of developers, lest our classics be forgotten:

The Rise of Worse is Better

I and just about every designer of Common Lisp and CLOS has had extreme exposure to the MIT/Stanford style of design. The essence of this style can be captured by the phrase ``the right thing.'' To such a designer it is important to get all of the following characteristics right:

• Simplicity-the design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation.
• Correctness-the design must be correct in all observable aspects. Incorrectness is simply not allowed.
• Consistency-the design must not be inconsistent. A design is allowed to be slightly less simple and less complete to avoid inconsistency. Consistency is as important as correctness.
• Completeness-the design must cover as many important situations as is practical. All reasonably expected cases must be covered. Simplicity is not allowed to overly reduce completeness.

I believe most people would agree that these are good characteristics. I will call the use of this philosophy of design the ``MIT approach.'' Common Lisp (with CLOS) and Scheme represent the MIT approach to design and implementation.

The worse-is-better philosophy is only slightly different:

• Simplicity-the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.
• Correctness-the design must be correct in all observable aspects. It is slightly better to be simple than correct.
• Consistency-the design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency.
• Completeness-the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.

Early Unix and C are examples of the use of this school of design, and I will call the use of this design strategy the ``New Jersey approach.'' I have intentionally caricatured the worse-is-better philosophy to convince you that it is obviously a bad philosophy and that the New Jersey approach is a bad approach.

However, I believe that worse-is-better, even in its strawman form, has better survival characteristics than the-right-thing, and that the New Jersey approach when used for software is a better approach than the MIT approach.

Let me start out by retelling a story that shows that the MIT/New-Jersey distinction is valid and that proponents of each philosophy actually believe their philosophy is better.

Two famous people, one from MIT and another from Berkeley (but working on Unix) once met to discuss operating system issues. The person from MIT was knowledgeable about ITS (the MIT AI Lab operating system) and had been reading the Unix sources. He was interested in how Unix solved the PC loser-ing problem. The PC loser-ing problem occurs when a user program invokes a system routine to perform a lengthy operation that might have significant state, such as IO buffers. If an interrupt occurs during the operation, the state of the user program must be saved. Because the invocation of the system routine is usually a single instruction, the PC of the user program does not adequately capture the state of the process. The system routine must either back out or press forward. The r

The Venn Diagram of Irrational Nonsense

Available here, for your pleasure (scroll down to BSOD). Someone told a story here once about having it on their computer, when the manager walked in and saw it and nearly fired them for having that server running Windows.

American have even more urgent matters like this, but as everyone pretend that nothing is happening, better focus in new periodic tables.

Or a lot. But the worst thing will be, if even happen, that you will realize that you made it possible.

Who says they even need to claim that so-and-so change fixed it? One time when I looked around Launchpad, a common way I was seeing issues getting closed was someone coming several months later and being like "this was reported for 12.10, can you reproduce it in 13.04?" and then closing it as incomplete when the user who has probably switched to a similar package or another distro at that point no longer cares.

JWZ on this: http://www.jwz.org/doc/cadt.html

as described at http://www.jwz.org/hacks/#youtubedown is a nice script that you can run on the command line.

as described at http://www.jwz.org/hacks/#youtubedown is a nice script that you can run on the command line.

1. On modern X servers the video buffer is shared, and media playback is done by direct writes into a shared buffer. If I am wrong, or you mean something different, can you provide a link? (And on a side note, I've never seen systematic video problems traceable back to X, only incidental ones, and no system is free from those).
2. X worked in days when the network standards were slower and less responsive, and today it should be worse? If there is too much communication, that is partly bad toolkit design. The alternatives of shoving full bitmap images over the lines for remote rendering can hardly improve the situation.
3. Boohoo. Complex problems lead to complex code. Oh those poor programmers, they don't get to reinvent the wheel for fame and glory. Fuck them.

I mean, NIH is one thing, but this kind of thing goes way past that. Ubuntu is in the full-throttle grip of CADT.

I'm a database guy so this hurts to write. JWZ wrote an email client. It worked. Netscape decided to switch to a database. It didn't work. JWZ wrote about it in addition to his line that: "To a database person, every nail looks like a thumb. Or something like that." http://www.jwz.org/doc/mailsum.html

It might be interesting to read The Rise of "Worse is Better"

That's a great article for high-brow programmers who want to triple-plus-abstract and design-pattern everything. You know... the folks who Joel Spolsky calls "architects astronauts". However, notice that this article is readable and thoughtfully characterizes the two coding styles it trying to differentiate. Fundamentally, this person knows their craft.

This is unlike some of my coworkers, who still embedd SQL straight into their GUI's. (I know of one of our apps where all the methods have the same 30+ parameters being slopped around [to represent a row from table X] because the original dev team couldn't be bothered to create a class called "X" to represent the concept of X and so pass around 1 reference.)

These people aren't heroic real-world veterans who sagely ignore the pretentious chatterings of academics... they're simply folks who don't understand how to express themselves clearly in code, much less the runtime environment, compilation process, or other fundamentals of the basic tools they've worked with for the past ~5 years.

It might be interesting to read The Rise of "Worse is Better"