that's precisely why i actually worked hard and risked destroying my business by losing access to all data on a critical business laptop, documented the process of removing libsystemd0 from it, and *then* wrote the article.

unlike the people you refer to, i actually *did something*.

then, i contacted the devuan team and informed them about what i had done, so that they may consider properly replicating what i'd done as maintainable debian packages. so they now have a way forward where previously they would have been worried that their efforts would result in many people still having to remove huge numbers of packages - desktop GUIs, sane-utils, cups-daemon, pulseaudio and anything that depends on it, clamav and many many more. i've demonstrated that you *don't* have to remove all those packages and that you *can* still have a functioning debian desktop... without libsystemd0 even being on it.

can you please do me a favour and make those thoughts known on the following wine bugreport? http://bugs.winehq.org/show_bu...

  the reason i ask is because there is critical functionality in wine that should never have been allowed to go so long without being implemented, and it's Named Pipes "Message Mode". the problem with message-mode is that there really is no good POSIX equivalent, and AJ - the paid-up employee - is in such a dominant and abusive position of authority that nobody may challenge his dictatorship. the only option left to implement anything remotely resembling message-mode under the extreme and fascist technically-tight conditions dictated by AJ is a non-portable hack using a little-known feature of TCP sockets that is *only* implemented in the linux kernel.

i mention this in the context of what you say to illustrate that the problem you highlight is not just restricted to one piece of software (systemd), but is a common problem across many of the critical pieces of software that we are using today. and the worst part is that *in each case* it is extremely difficult to gain sufficient technical expertise in order to engage with these people.... but even if you *do* have the technical expertise they often are so entrenched in their day-to-day mindset as absolute... "gods of their world" that even a reasonable and rational argument is completely ignored.

the long and short of it is that GNU/Linux software is getting out of hand, and is becoming so complex as well as so prevalent that the dominance and arrogance of just one person or company can have massive detrimental consequences for a *lot* of people. i'm really not sure what can be done about this, if anything.

for the average end-user or sysadmin? yes.

and what skills must the average end-user or sysadmin have in order to install that replacement functionality? do you think that the average end-user has the time to learn how to modify debian packaging correctly in the way that i documented? if you wanted to install mdev or eudev as a debian package, what do you think it would take for the average end-user to successfully do that, even assuming that they were capable of (a) finding those replacement packages and (b) having the courage to risk destroying their system by installing them.

not even *i* will install such low-level replacements for udev on mission-critical systems. i'm investigating them, looking for something suitable, but i sure as hell won't risk putting them on any of the systems i manage without a proper audit.

and that's the problem, there, that there *isn't* a packaged alternative to udev yet. a unilateral decision was taken some time back to integrate systemd and udev, with blatant disregard for the consequences. now in order to have a working system i am forced to *entirely disable* udev - that's insane!

not everyone in the world is as intelligent as you or i, dude.

we can't. the reason is simple: security updates and software updates will be incompatible. i actually maintain a hell-on-earth system for a client. the choice to do so is entirely mine, i have to point out. it's hell because i disagreed with putting KDE 4 in front of clients who are used to the simplicity of KDE 3.5, and i disagreed with moving them over to Gnome because, well Gnome is a different kind of hell (for me), involving being completely unable to remotely ssh in and hand-edit config files in a pinch. with KDE 3.5 it is still possible to do that.

so i ended up upgrading to Trinity Desktop, but this is after leaving the system running debian 6 for as long as possible. the upgrade was... fraught. then i had (in December 2014 - so only a couple of months ago) to buy and install a new printer (because we couldn't get the old one). that new HP printer wasn't recognised by the version of hplip that was on the system (3.12).

so i did an "apt-get upgrade hplip" - and what do you think happened? it said "to satisfy your request we require to remove Trinity Desktop and install KDE 4".

the reason was because the Trinity Desktop Team do *not have the manpower* to keep such a large old software base completely up-to-date with debian/testing. ... so i was forced to compile hplip from scratch, from source code! *fortunately* HP saw fit to include an extremely well-written and well-thought-out script that detected the OS, installed the build dependencies and generally got on with the job. i was really impressed.

now, the only reason i could contemplate this was because i am an experienced GNU/Linux systems administrator, but do you *really* think that the average person will be satisfied to "use older software" as you suggest?

this is the crux of the situation: that we *are* forced to such extreme polarising choices. and that's why i did what i've done - demonstrate that it's possible to remove libsystemd0 which is being shoved down our throats. i *don't care* if libsystemd0 is good or not: i object to it being forced onto people.

"But it also suggests an incursion of anti-science, anti-vaccine thinking in one of the smartest regions on Earth."

ooor, it suggests that there are more intelligent people in one of the smartest regions on Earth, who have actually thought through the consequences of their decision. _maybe_ they see the harm caused by vaccinations. _maybe_ these people have thought, "gosh, y'know, giving my young child a massive simultaneous hit of diseases for their body to fight all at once isn't such a good idea, given that healthy humans never *ever* get more than one disease at a time because once activated the immune system goes into hyper-drive".

_maybe_ these people have had the thought, "y'know, humanity has survived up until this point, by fighting off disease and as a result each individual develops its own strong and healthy immune system, and the weaker ones don't survive. _maybe_ i am doing my child - and humanity - a favour by not following the herd".

you think it's _good_ to carry out mass-vaccination of a species?? how did you get so completely and utterly brainwashed that you have to claim it's "anti-science"?? f***k you you completely insane person - and stay the hell away from my family.

how is 96boards different from a pc? or how is the situation that 96boards presents different from a pc? apologies, because the question, in its brevity (but mainly through the use of the word "it"), is very unclear.

working on it. i'm creating products on either side of the standard to get it started, and will continue to do so for at least a decade until the standards reach critical mass.

i'm the author of the EOMA standards, including EOMA68, so i have spent something like two years developing and refining hardware standards that will not confuse end-users. http://elinux.org/Embedded_Ope...

the 1.0 (i.e. final and absolute unchangeable) version of the 96boards "consumer" standard from 96boards will be going on the list of alternative standards, as, sadly, another example of a standard that will result in end-user confusion, annoyance, product returns and, ultimately, failure.

the reason is incredibly simple: an end-user standard MUST NOT have optional interfaces. i do not understand why people developing standards do not understand this. page 7 of the 27 page v1.0 specification states, clearly, "1 OR 2 MIPI CSI-2 ports MAY be provided on the expansion bus interface" and "From 1-2 lanes MAY be implemented on the CSI1 port interface". now whilst the latter is absolutely fine (because negotiation takes place at the hardware-level, so either host or client will correctly negotiate 1 or 2 lanes), the former most definitely is NOT.

let's think it through. here's a simple scenario. an end-user buys a 2-lane box, and a lot of expensive camera equipment. they then find that the box is too slow, and need to upgrade. so they go out and buy another box, and, BY MISTAKE, when they get it home, they discover that they only bought a 1-lane box. as there is NOTHING WRONG with it, they may NOT return it as faulty under warranty.

additional confusion results from page 8, over the options that the 3rd USB port MAY be a USB-OTG port. again, people will buy a system and a set of peripherals, relying on the USB-OTG capabilities... and then upgrade at a later date and make the mistake of not knowing what the hell is going on until it's too late. they investigate further and find "whoops, i bought the wrong system: this one doesn't have USB-OTG power damnit".

DC power requirements, page 8: again, more confusion when upgrading.

2nd (optional) UART, page 9: more confusion results.

a summary is given on page 12, where the moment you see the word "optional", count them. that becomes a permutation of the number of possible things that an end-user has to check when first selecting and then double-checking on upgrading the device. i count (if you include the USB confusion and the power options) at least *SEVEN* possible "options", giving... someone else can do the math here, it's what... over a hundred different permutations at least.

and then, when you get to the end of page 12 only then do you discover that the expansion board connections may be used as GPIO!

*sigh* i have to say that this really does not look like a very well-thought-out standard, at all.

the important question is did the procedure solve the intestinal problem?

note: the use of less-than and greater-than within what i have written above has been mangled by slashdot, resulting in it being unintelligable at a key strategic point. that point is when script language is mentioned. it's supposed to read less-than script language equals python greater-than and less-than script language equals javascript.

when i started the pyjamas-desktop project i assumed that the "open-ness" that is written into the mozilla foundation charter would be an inviolate quantity that they would adhere to. taking this on faith i found the python-hulahop bindings of the OLPC project to be perfect to allow HTML5 DOM to be entirely (even exclusively) manipulated *python-side* instead of using javascript.

for anyone not familiar with the difference between pyxpcomext and python-hulahop, pyxpcomext was a project funded in 2000 by the mozilla foundation to *literally* embed python - making it a peer language of javascript - *within* a firefox browser. you downloaded a whopping 10mbyte extension for either linux or windows and you could do *not* just script language equals javascript and it would work, *including* accessing the *FULL* and complete DOM manipulation functions that we normally expect to have from javascript (exclusively, as it turns out in most peoples' mindsets).

python-hulahop on the other hand is (or was) a pygtk widget which allowed one to create a GTK window that happened to have a Gecko (HTML5/DOM) engine running in it, which *happened* also, amazingly, to provide one with the full set of DOM manipulation functions, starting from a python function GetDOMDocument() and going from there to the thousands of functions one normally expects to be the exclusive monopolistic domain of javascript.

the irony is that the python-hulahop project was only created so that the OLPC team could create their own embedded browser (in python), and they went to the trouble of using just a tiny fraction of the available functionality to implement the "Go" button, "Back" button, history and so on, all using the python bindings to the internal XPCOM interface that allows direct access to the full functionality of the Gecko Engine.

one other thing is needed to be explained before we can get on to what the problem is: XPCOM was "inspired" by Microsoft COM, and it *could* have been absolutely brilliant. COM is... deeply awe-inspiringly powerful, it is that flexible and ubiquitous. you may have heard me mention in the past that COM is what allows binary Active-X components compiled *TWO DECADES* ago to still be useful and useable on modern Windows (and Wine) systems today, even though in some cases the company that created them will have gone out of business.

technically the problem with XPCOM is that they forgot to implement co-classes, meaning that the only choice available to them is to *remove* quotes broken quotes functions and to constantly upgrade upgrade upgrade. this problem is at the heart of every single complaint for the past *TEN YEARS* by 3rd party developers using the Gecko Engine in java or c++ applications. they're SICK of having to recompile their applications to suit the mozilla foundation's schedule, particularly as it is such a mammoth task and may need to be done frequently (especially due to a security fix).

so with that as background we start to get some hints as to inherent problems that have been stressing out the developers for some considerable time. ...so what did they do about it? well, they responded to the "threat" of webkit (the engine behind chrome) by announcing a "speed, speed, speed" pathological binge - this was around 2010 or 2011. the ABSOLUTE top priority became not to be "open" - even to the extent of violating the spirit *and* the letter of the mozilla foundation charter - but to be "The Best". "The Fastest".

one of the first things that were removed was a single line from a header file - a "friend class" declaration. this one tiny change was utterly profound: it was a key absolutely critical change that prevented and prohibited the python-hulahop source code from accessing the XPCOM infrastructure. without that "friend class" declaration, there was absolutely no way that the GNU/Linux distros could take the standard gecko / xulrunner source code and have hulahop get that key strategic pointer to the Gecko Engine's top level XPCOM object.

when i pointed out how severe the consequences of this ill-considered unilateral decision were to the top people at the mozilla foundation, i was told "it's not a priority. speed is our priority".

when i pointed out that this violated the mozilla foundation charter i did not receive a response.

the second problem was that a couple of the functions (XMLHTTPRequest was one of them) had optional parameters that were only available via a hack of accessing the *javascript* parameter stack. when calling the exact same function from python, c++ or java, obviously this javascript-parameter stack would be empty.

basically i was running into the limitations of XPCOM not having co-classes, but from a different angle. the concept of co-classes are what gives e.g. c++ its "optional parameters" or its ability to have entirely different parameters for any given function, and the compiler works out which is the best one to use: co-classes is a *runtime* implementation of that, and it's utterly cool as it allows one to provide binary backwards-compatibility (you simply keep the old functions as-is and just add new ones which implement new functionality), a means to implement optional parameters (you provide functions with 3, 4, 5 and so on parameters) and more besides.

so i created a patch which extended the XMLHTTPRequest function out to 5 parameters (allowing me and anyone else to call it from c++ or java). the patch was *not accepted*. instead, some blithering idiot created an amazing idea of modifying the functions to take an "optional number of parameters" parameter. imagine having to write c++ code where one of the parameters told the compiler how many parameters the function had, and you start to get an inkling of quite how spectacularly stupid this idea of theirs really was.

again, when i raised quite how strategically vital this area was, and how important it was that this be discussed (and this incredibly dumb idea not allowed), i got nowhere.

the patch went in - and it entirely destroyed the ability of pyxpcom to correctly call those functions *AT ALL*. XMLHTTPRequest - an absolutely *critical* function to the operation of about 80% of pyjamas-desktop applications - had just been utterly destroyed by some dick being allowed to make arbitrary decisions with blatant disregard for other projects that critically depend on Mozilla Foundation funded technology.

so now, if you want pyjamas-desktop with a gecko (xulrunner) engine, you are forced to use versions 1.9.11.1 (the last known good variant from a stable distribution), or xulrunner 7.0 (which briefly made its way into debian/testing for a short period of time) and is - was - only really available in binary precompiled form from activestate.com in their komodo editor.

in 2011 i made a brief effort to compile up xulrunner 9.0 in the hopes of saving python-hulahop - making it a dependency - but the thought of becoming both an upstream and downstream maintainer of such a vast amount of code *UNFUNDED* was just too much.

so the summary is: congratulations to the mozilla foundation for violating your charter - for closing your doors to developers who were actually more interested in expanding the reach of your source code than you are. may you pay for following your chosen path by learning painfully for your closed-minded thinking.

has anyone else noticed that typos have become much more prevalent in slashdot articles in the past year, and that they are less-often corrected? sited, it's, and many more.

the nice thing about a modular system is that just as the modules may be discarded from the phones and re-purposed (in this case the idea is to re-purpose them in compute clusters), so may, when there are better more powerful processors available, the modules being used in the compute clusters *also* discarded... and re-purposed further once again down a continual chain until they break.

now, you may think "phone SoC equals useless for compute purposes" this simply is *not true*. you may for example colocate raspberry pi's (not that i like broadcom, but for GBP 25 who is complaining?) http://raspberrycolocation.com... - cost per month: $EUR 3. that's $EUR 36 per year because the power consumption and space requirements are so incredibly low.

another example: i have created a modular standard, it's called EOMA68. it re-uses legacy PCMCIA casework (which you can still get hold of if you look hard enough). the first CPU Card is a 2gb RAM dual-core 1.2ghz ARM Cortex A7, which as you know is based on the A15 so may even do Virtualisation. i did a simple test: i ran Debian GNU/Linux on it, installed xrdp, libreoffice and firefox. i then ran *five* remote sessions from my laptop, fired up libreoffice and firefox in each, and that dual-core CPU Card didn't even break a sweat.

so if you'd like to buy some compute modules *now* rather than wait for google project ara (which will require highly specialist chipsets based on an entirely new and extremely uncommon standard called MIPI UniPro) the crowdfunding campaign opens very shortly:

https://www.crowdsupply.com/eo...

once that's underway, i will have the funding to finish paying for the next compute module, which is a quad-core CPU Card. after that, we can see about getting some more CPU Cards developed, and so on and so forth for the next 10 years.

to answer your question about "interconnect", you have to think in terms of "bang-per-buck-per-module" in terms of space, power used as well as CPU. a 2.5 watt module like the EOMA68-A20 only takes up 5mm x 86mm x 54mm. i worked out once that you could get something like 5,000 of those into a single full-height 19in cabinet - something mad, anyway. you end up using something like 40kW and you get such a ridiculous amount of processing power in such a small space that actually it's power and backbone interconnect that become the bottlenecks, *not* the Gigabit Ethernet on the actual modules, that becomes the main problem to overcome.

bottom line there's a lot of mileage in this kind of re-useable modular architecture. help support me in getting it off the ground!
https://www.crowdsupply.com/eo...