It seems to me that the presence of a "bazillion knobs" is a bug in itself. A stable system can not depend on puny humans for its operation—nor should a design be able to blame puny humans for its failure.
The maxim "every tuneable parameter is a design weakness" applies for top-down design, but not so much for something as foundational as the IP layer.
In the 70s, TCP's inventors imbued it with solid fundamentals, but could not have anticipated how the protocol would need to evolve in the future w.r.t. security and performance. For IPv6, there are unknowns that will only encountered at scale, and implementors are hugely motivated to play fast and loose with the spec. (TCP Fast Open converts!)
Bottom-up systems have inherent wiggle room, and shipping them with sensible defaults is only possible in the short term. That's not to say we should design over-complicated systems, but just that fine tuners are not a weakness.
It's a very noble goal, and a pity HN has only one upvote per reader :-)
But, designing a ship that 10 years post-release can fly and dig under ground on a whim is a pretty high bar - and would be interesting to learn of successes elsewhere, if you know.
Some of the "weird" IPv6 knobs today are actually very useful, though from what I know, I must've been one of the first known instances to abuse some of the non-defaults at a 10K+ users' scale.
So, I'd say - keep "no knobs" as a goal, but still leave the dirty knobs somewhere to turn in case of emergency. You'd be thanked, if by accident your protocol get used 15 years later :-)
> My philosophy for a long time has been "every tunable parameter is a design weakness, and every one that must be tuned is a bug."
It's completely true that good defaults are essential. But no one person is competent to make a decision for everyone everywhere. It should always be possible to change something but ideally it shouldn't be necessary.
The interesting thing about software: excepting DRM, it's always possible to change something. Don't like a "fixed" parameter in your IP stack? Patch your kernel.
I'm honestly surprised people don't take more advantage of "tuning the source" as an solution to providing end-user flexibility (the only project that I can think of that does is nginx.) Maybe it's because we have "dev ops" (devs who end up doing ops) but no "op devs" (operators who know how to code.)
It's still possible even with DRM, it's just more work. You have to get out a debugger and write new code.
But what I meant was that you shouldn't try to make modifications impossible. Yes, it's futile anyway, but it's a bad idea independent of that.
If you've designed the system right then the users shouldn't need to modify it. So if they do it's a signal that you've missed something and then you can improve it. Whereas if you declare yourself the final authority and refuse to facilitate user modifications, or worse actively interfere with them, then any mistakes you make are silently uncorrectable.
100% agreed. This is why I'm liking elementary OS so much. I still need to pop into the command line for some things, but the standard GUI software is less excessively configurable than most. They have an HIG and a small community of developers who actually pay attention to it.
A lot of it is based on the GNOME core applications, so it's similar. I haven't used GNOME enough to say more than that. For the people who want extra options, there's elementary-tweaks, similar to gnome tweak tool.
How many users will want to change the file naming or folder hierarchy convention for their music library if they're managing them through a GUI application? Why is there a big list of "visible columns" checkboxes instead of setting that by right-clicking the columns? Does crossfade really need a whole tab for a checkbox and slider (and why does it need a checkbox when 0 seconds implies no fading)? Do people actually use crossfade anyway? I never have.
In short, there's room to clean a lot of things up. Even if it's minor, doing it across the entire system makes things a lot nicer. Plus there are some additional system-wide standardization features that elementary is doing, which should prevent a lot of inconsistency from software from all reinventing the wheel in different ways:
How many users will want to change the file naming or folder hierarchy convention for their music library if they're managing them through a GUI application?
I do.
Do people actually use crossfade anyway?
Yes.
The past decade has shown a disturbing trend in design. B-level designers think they can ape Apple by optimizing for the middle of the bell curve and alienating the edges. The problem is that the actual distribution of feature usage is multidimensional in a big way, and these designers delete features on one axis that otherwise very average users absolutely depend on.
There's the saying that 80% of users use 20% of features, but no users use the same 20%.
I'm not saying it's ideal for everyone, but it's an Ubuntu derivative, and it will continue to exist alongside Ubuntu. Noise will exist alongside Rhythmbox. I like a lean, well integrated player as the baseline "everyone gets this by default" option. Out of curiosity, what's the naming/organization system that you use, and is there a reason you don't like "Music/Artist/Album/# - Song.mp3"?
And re:crossfade, if people other than me really use it, then my complaint is that they added an entire "playback" tab in the settings for it. If there's only one playback setting, give it a header under General. It's the visual equivalent of a "for i in range(0):" loop; all it does is make your interface harder to read.
Noise is still an early version and I'm sure there are features that will be added, but "Print CD jewel case insert" isn't on the high priority list. That might have been neat when iTunes first added it, but it's just more cruft now. 1% of people might burn CDs in iTunes today, and only 1% of that 1% will even realize they could print an insert to go with it.
Even on OS X where every computer ships with a pretty effective (if not always snappy) media player, there are plenty of alternatives for people who don't like iTunes.
> and is there a reason you don't like "Music/Artist/Album/# - Song.mp3"?
There are tons of reasons I don't like that format. It's extremely limiting and it only applies to a few genres of music. It tries to fit all music into a rigid hierarchy of bands, albums, and tracks, a hierarchy which applied to a reasonable amount of popular music from the '70s to the '00s, and it makes me wonder if the designers of music players ever listen to anything else.
Suppose the song is a collaboration. Which artist directory does it go in?
Suppose the song is a promo track that you downloaded from a band's website or from Bandcamp. What's the album? What's the track number? What happens when the track is eventually released on an album?
Suppose the "song" is the third movement of Bach's Unaccompanied Cello Suite No. 1 (BWV 1007) as performed by Yo-Yo Ma. Who's the artist? What's the album? (If you're going to say "the album that Yo-Yo Ma's recording was released on", you'll have to be more specific.)
Now can you give answers that put things in the same organizational scheme when it's the second chorale of Wachet Auf (BWV 140) as performed by the Bach Cantata Pilgrimage, directed by John Eliot Gardiner?
Suppose the song is Monstrous Turtles, by Zircon, a remix of Koji Kondo's "Super Mario World" music, released as OCRemix #1558. Is "OCRemix" an album under "Zircon"? Is it track number 1558? What about the fact that most OCRemixes are not by Zircon? Does it go in the same place if you download it from Zircon's web site instead of OCRemix?
> There are tons of reasons I don't like that format. It's extremely limiting and it only applies to a few genres of music. It tries to fit all music into a rigid hierarchy of bands, albums, and tracks, a hierarchy which applied to a reasonable amount of popular music from the '70s to the '00s, and it makes me wonder if the designers of music players ever listen to anything else.
And here are Rhythbox's five options for library folder naming.
Your library sounds like a perfect case for unchecking the "Keep Music folder organized" and just managing it yourself, since there's no single pattern that will work for the whole thing. Incidentally, that's the one library organization option that elementary OS has.
And taking another look at Rhythmbox, either there's no option for "Let me organize my own damn files," or they hid it somewhere unrelated. Maybe you can launch it with a command line flag to do that...
Millions of people are using it today, one and a half decades after it was conceived. It's not perfect but nothing is.
If you have examples of tech to compare with - please bring them in!
EDIT: and yeah, a lot of knobs does sound like a bit of a poor design, but on the other hand, today, 1.5 decades later, I am grateful I can tweak some of the defaults!
Again, if you know something knob-less that'd get flawlessly deployed in 15 years after it was designed - shout, would be very useful to try and learn from that success!
The nearest comparison to IPv6 is DNSSEC. IPv6 has done a little better, but that's not saying much. Both suffer from massive over engineering, and lots of false starts and back pedaling over the years. Trying to solve too many problems, and therefore failing to solve the one problem that's of immediate concern.
False starts and backpedaling are also known as "iterating". It's disappointing that many of the planned features never got production-ready. But the protocol is now more likely to be implemented than ever before, which is the primary "feature" to which all others are secondary.
I was looking for the example of the sparkly unicorn protocol from 2000 the people seem to evoke, which does not need any knobs and is available on every device to update some other protocol from 1970s.
(I suppose the hard meta-question to protocol designers is: how do you make sure your children will not hate you for the protocol you have imposed on them today ?)
UTF-8 updating ASCII is probably the best example of this going well. And even then there was a terrible mistake made in the design of Korean encodings which had to be fixed.
Both yours and tedunangst example (SSH) have one important commonality which is not present in IP: they become immediately available to two parties as soon as these two parties upgrade.
With IP, all the intermediate nodes need to upgrade to use the new protocol (tunneling tricks aside).
This difference would probably be a significant factor in the speed of adoption. Tunneling obviously can emulate the 2-party model, but then we're left with the problem of managing the crazy amount of tunnels (and security issues) and sunsetting them.
I have no experience with Korean and Unicode but, I guess, it's jamo composition?
With it, there are two distinct and not-really-compatible (since anyone in real world practice rarely cares about Unicode normalization) ways to specify a single Hangul character. And that should make text processing a bit painful.
Anyone who writes software to deal with unicode really better care about unicode normalization!
You are going to have all sorts of edge case bugs and unexpected behaviors if you don't, definitely not limited to Hangul. There are multiple un-normalized ways to write all sorts of on-screen glyphs, including Latin alphabet ones.
I thought wbl meant something to do with the combination of Korean and UTF-8, whereas jamo composition is no more related to UTF-8 than any other unicode encoding.
They moved the Korean encodings at one point in the early 1990's. Luckily this was before anyone used it, but it was still a big mess. I don't know why they had to move it.
...and thanks to the knobs for being able to workaround the day1 bug uncovered just this year in at least one of the widely used vendor's server implementations while getting the fix.
But yes, with just 2 parties involved into any instance of the protocol enabling easy upgrade/downgrade path, and tight engineering it is indeed a beautiful protocol.
I would say IPv4 had that property. Not exactly knobless but there are reasons it replaced just about every other networking protocol in existence and simplicity and robustness probably had a lot to do with that. Of course hierarchical routing was a huge feature for the Internet but not necessarily compelling enough to drive out every other LAN protocol.
> I would say IPv4 had that property. Not exactly knobless
I can tell you haven't tried creating/setting up your own router with NATing, separate subnets (secure, insecure), inbound and outbound VPNs, firewalling and traffic shaping. Or basically anything non-trivial with IP in general.
The amount of knobs which you can (and must) set correctly for this thing to fly is enough to give an experienced engineer severe paranoia.
Actually I have done most of those things at one time or another.
I'm not saying IPv4 is simple (especially if you want to do complex things with it) but it works well when configured correctly and is simple enough to be deployed in businesses of all sizes as well as home networks.
I didn't get involved with networking much until shortly after most other protocols were rapidly disappearing but the fact that IPv4 replaced IPX, DECNET, AppleTalk, etc in only a few years time suggests that it probably wasn't that much of a nightmare to set up, even in it's early days.
My concern with IPv6, based on this post, is that it may have lost some of the robustness and relative simplicity of IPv4. I mean layer 3 <-> layer 2 address mapping is fundamental to any network and if that's breaking with IPv6 it could be a pretty serious issue.
