SoylentNews is people
SoylentNews
https://lists.debian.org/debian-devel/2014/11/msg00174.html
Joey Hess has apparently left Debian after 18 years, stating that the Debian Constitution is leading Debian in "very unhealthy directions".
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
You are always busy.
(Score: 2) by Pav on Saturday November 08 2014, @02:18PM
I've installed:
apt-get install popularity-contest sysvinit-core
...even though he doesn't see what all the fuss is about re: systemd. I think the new constitution kept the devs fighting eachother so much that they were not focused outwards enough and so didn't keep the communication channel with their users open.
(Score: 5, Insightful) by Pav on Saturday November 08 2014, @03:28PM
Debian and free software in general has felt subverted somehow... and for some time. I'm almost almost paranoid enough to feel there's some kind of updated halloween document out there circulating between Microsoft, Redhat, Ubuntu, Oracle etc... :) I think I've noticed some patterns... they'd certainly make good bullet points in such a document. Creative writing time:
* Hire away the developers: A paycheque often means control, but hackers are difficult to herd, and there's a right and a wrong way to do this.
- Apple hires FreeBSD desktop devs: This was wonderfully executed, and the FreeBSD desktop sagged and became a non-entity almost overnight. This also meant the FreeBSD desktops small but tech savy userbase was more likely to shift to Apples product - developers, developers, developers! ...not to mention free advocacy in tech-savy forums. Most of them even felt they'd made this decision themselves! The license enabled keeping code proprietary, and we all know the retention benefits - the best coders aren't fond of leaving a project they're personally invested in, and Apple now has monopolies on many such projects. It's even better than the good old days - proprietary goodness, with the uninteresting parts of the OS being largely maintained by volunteers and other parties.
- Oracle buys MySQL: This was poorly executed. Granted, Oracle acquired MySQL by accident, and the GPL2 isn't the most company-friendly license, but if they'd also hired the original developers and slowly tempted them away with interesting but proprietary projects MySQL probably would not have forked, and most likely would have lost vitality over time. Only Oracles directors know if this is something they might have wanted, and we are not privy to this information at this time.
* Infiltrate and subvert organisational structures:
- Microsoft vs ISO document standards: Superlative example. Enough said.
- NSA vs encryption: Again... tremendous, as one would expect from such an organisation.
- Mozilla foundation: Several of our members (including Microsoft, Google etc...) fund this foundation. Other than Microsoft originally benefiting by having a browser competitor as a foil for antitrust lawyers, and embedded Google+Bing search it's unclear what benefits we might acrue, but funding is a powerful reign as our congress critters know well.
- Debian constitution: Social engineering in the right document can enable a coup. Debian developers are now too busy playing politics to communicate with their users, with predictable results - wonderfully done! Both Redhat and Ubuntu are warring by stuffing key decision making committees to decide if Debian dies or becomes an Ubuntu satellite. It will most likely do a little of both.
* Move from simplicity to complexity: ie. gently lifting technology from the fingers of the lone hacker under the guise of genuine technical benefits. The life of a lone part-time developer can be made much more difficult simply by increasing complexity to a point where only a full time company man can meaningfully contribute. Projects that remain too simple will never be truly "tamed". Some examples of complexity induced control:
- systemd: This is schadenfreude in code. Company hardware driver-devs repeatedly waste costly time on unstable APIs in the Linux kernel, supposedly for technical reasons that mostly don't benefit them... and are STILL criticised for guarding valuable IP in closed code. Now we've forced large sections of the Linux community to accept similar reengineering effort which mostly doesn't benefit them, or else move to a platform more amenable to our control (eg. one of the BSDs).
- OpenLDAP: This project has always been controlled by companies whos lifeblood is herding customers to the cash register with complexity-pain, and as a result OpenLDAP is generally only installed for the largest and most profitable customers. It also benefits from the NSAs standard-subverting efforts - a secure deployment is almost impossible even for relative experts.
* Astroturfing: hackers are a stubborn bunch, but even they are susceptible to the oldest mind control technique known to man - repetition... repetition... repetition! It's even possible to use the developers you've hired as astroturfers, many will even do this unpayed - it's natural for most to gradually begin drinking your koolaid. Emphasise your projects benefits (technical, ease of use etc...), and de-emphasise freedom and flexibility as unimportant and irrelevant to mass acceptance.
....wow... that was much longer than I'd intended... I'll stop here.
(Score: 1) by fritsd on Saturday November 08 2014, @05:04PM
I think your tin-foil-hat is screwed on more tightly than mine ;-) , but I have one additional item to contribute:
* Hubris/shame about competence: if you have doubts about systemd, maybe it's because you're really *too stupid* to understand its magnificence.
This is an illogical but very effective technique.
To take myself as an example: I'm not a Debian Developer. I'm a long-term Debian user. I know that I'm far from the smartest or most competent Debian user.
But I'm old enough to know that if a system is too complex for *me* to use on days that I'm not smart, it's probably also too complex to maintain for the average system admin.
This leads directly to your point about "moving from simplicity to complexity": simplicity is a virtue for everyone that works with computers, even if you're smart enough to understand systemd ;-)
Maybe I *am* too stupid to understand the benefits of systemd's assimilation efforts. It is very possible. But I don't want it installed, because it's going to be more difficult by the day to get rid of it.
If you're too stupid to understand something, that still leaves the unresolved issue of whether that something is of benefit to you, or not. You only know that *you* can't figure it out on your own without help.
A perfect example is the belief that voting computers are better than red pencil (cartoon in Dutch):
http://wijvertrouwenstemcomputersniet.nl/other/strip/ [wijvertrouwenstemcomputersniet.nl]
I hope I'm making some sense here :-( I do have a bad cold atm.
(Score: 1) by novak on Saturday November 08 2014, @08:57PM
This is spot on. I think it is generally non-malicious, but simply a victim of software design trends. In general, software has been getting heavier and more complex in order to be more understandable since it was first invented. There's always pushback from the "lone hacker" types- back in the day you had to build your own computer and write drivers for all your hardware, but that was simple enough that you could get done with that and use your computer (both kb of RAM). Now OSs are at least millions of lines of code, and require large teams to maintain. Even relatively small projects are gaining size and requiring larger and larger teams.
And in general, that's a thing that makes people's lives easier. When was the last time you wrote a driver? Probably never (unless you're a kernel dev) but at the same time, if your hardware is without a driver for your OS, you were probably unable/unwilling to do much about it. It would probably require reverse engineering some obscure protocol which is documented nowhere.
I enjoy keeping my system relatively minimal. But at the same time, someone from the 90s would not be able to believe how much bloat there is on my OS. (Or that linux has come this far). But as linux is more and more controlled by large professional teams, it increasingly becomes dominated by the prevailing mindset of those teams, which is that adding complexity can bring benefits. I tend to disagree. But I think I'm increasingly in the minority.
novak
(Score: 2) by Pav on Sunday November 09 2014, @02:53AM
Never wrote any drivers, but banging on raw hardware was fun. I learned interrupt driven programming on DOS + mouse/soundcard/keyboard/video (pushing and pulling data from ports via INT10, writing interrupt handlers etc...). The Gravis Ultrasound was fun back in the day - a wavetable synth with up to 32 voices. Might have done some Soundblaster Pro playing also, but memory is hazy.
(Score: 1) by novak on Sunday November 09 2014, @06:03AM
I can appreciate people who are actually familiar with hardware. I'm too young to have used DOS a lot; I used it but only to learn the basics of a command line around the age of 8. The point I meant to make was that as software expands working with the hardware gets more and more complex, and also more unnecessary for the average user. I would guess you've observed this more directly than I have, if you've been programming that long.
novak
(Score: 2) by Pav on Sunday November 09 2014, @02:02PM
I'm no coder... but I felt the need to understand what a computer really is, and there's only one way to do that at a gut level ie. "touching" the hardware directly - no abstraction. In my first year at university we hand-compiled ASM to machine code and typed it into a hex pad connected to a Z80 processor, but I was overwhelmed by everything and didn't really understand what I was doing. My later hardware programming was for fun, and at my own pace. If I was advising a student wanting hardware programming experience today there are many options to get that gut understanding. The options I can suggest are:
* playing with FreeDOS and DJGPP with inline ASM and learning how to interface directly to hardware. This is probably preferable to other options because it can be done on a "real" computer. I actually made my own very simple "windowing" environment back in the day.
* playing with Arduino programming, perhaps directly in ASM, and interfacing with different peripherals/hardware.
* building a computer from scratch. There's a project from the sixties called the "paperclip computer"... this design could use updating for more modern electronic components, and perhaps handle some extra features. The bare basics of computing hasn't changed since WWII... it's just about making binary switching faster/smaller, and hooking binary logic to more interesting peripherals. I've even seen a binary adder implemented using wooden switches and marbles on YouTube(!)
(Score: 1) by novak on Sunday November 09 2014, @08:48PM
I've also thought that rather than teaching beginning programmers python or javascript, a better intro would be to get close to the hardware. Maybe that's just my own stupid idea but what originally fascinated me about computers was the really low level stuff- assembly code (or even shellcode), how to build logic gates and circuits out of transistors, and how operating systems work, and how to control things at the most fundamental level. Wanting to understand these secrets was what led me into programming, not wanting to write a basic "app."
I think the best intro to programming book I've personally seen is "Hacking: The Art of Exploitation." It takes you through writing a simple C program, and helps you dig into every facet of it. Basically, you wind up writing buffer overflow exploits of increasing complexity (against your own program), which teaches you more about how a computer works at a really low level than you could get out of anything besides actually building your own hardware.
novak
(Score: 2) by Pav on Tuesday November 11 2014, @11:09PM
Yeah, perhaps close-to-the-hardware is good... or perhaps a very high level and very low level perspective that meets in the middle? I guess different students have different things they'd want to know.
(Score: 2) by jackb_guppy on Saturday November 08 2014, @05:12PM
Ubuntu does not have sysvinit-core as a package for 14.04. :/
(Score: 2) by Marand on Monday November 10 2014, @07:19AM
Ubuntu does not have sysvinit-core as a package for 14.04. :/
That's probably because Canonical had been pushing upstart aggressively in the same way. Now that Ubuntu decided to switch to systemd too, following Debian's default decision, upstart's basically dead-man-walking. (Though upstart still seems to be default for Ubuntu right now)
I wonder if they'll eventually pick up the sysvinit stuff from Debian again? If not, there's still other init alternatives floating around.