There are CONSTANT statements that if you do not use systemd you will not be able to use primary Linux distros in the future, because all software will supposedly be gobbled up by it as a dependency... To try and now make out like those dont exist is pretty silly.
not "supposedly" - *really*. if you run apt-rdepends -r libsystemd0 | a bit of awk | sort | uniq there are four *THOUSAND* five hundred packages that, if you were ever to do "apt-get --purge remove libsystemd0" you would NEVER be able to install. that's a whopping FIFTEEN PERCENT of the entire debian package repository that you are prevented and prohibited from installing, should you ever make the decision that you wish to keep libsystemd0 off of machines that you manage!
the reason for this insane level of *hard* dependency is because lennart pottering is both the developer of libsystemd0 *and* many other packages such as pulseaudio... so of *course* he decided that pulseaudio had to include - as a hard dependency - one of his projects, libsystemd0. libsdl likewise also uses it as a hard compile-time dependency, along with about 100 other applications and libraries.
those applications and libraries then quickly spread as further hard dependencies to include the gimp, apache2-dev, php5 (??!), erlang, libreoffice, cups, bluez/bluetooth (because of the links to pulseaudio), *all* the games that use libsdl (i.e. pretty much all of them), *all* the music software available for GNU/Linux (because of the link to pulseaudio), openjdk7, the eclipse IDE, apache tomcat, the android SDK, i mean.... the list is a _real_ eye-opener. you can review it here for yourself:
unix was supposed to be simple. systemd is an abortion and one that most of us do not want.
good to see this protest post with a hand-tweaked system; but the fact is, we should NOT have to flip over backwards to remove a stupid should-not-be-there-anyway daemon and its evil libs.
Really, someone should get a dictionary for their birthday and read the definition for "unilateral" lol.
that's in.... *counts on fingers*... 9? days?:)
ok so let's look it up... a random google search shows these:
1. Of, on, relating to, involving, or affecting only one side: "a unilateral advantage in defense" (New Republic). 2. Performed or undertaken by only one side: unilateral disarmament. 3. Obligating only one of two or more parties, nations, or persons, as a contract or an agreement. 4. Emphasizing or recognizing only one side of a subject. 5. Having only one side. 6. Tracing the lineage of one parent only: a unilateral genealogy. 7. Botany Having leaves, flowers, or other parts on one side only.
yep. definitions 1 through 5 are perfectly relevant. unilateral. meaning that pottering made the decision and (2) did not consult any of us. he claims to be "listening to users" yet (4) in fact ignores everything they tell him and carries on regardless. he has therefore violated the implicit software freedom contract (3) between users and developers who choose to be of service to others.
so yeah. it would appear that yes i really do know english, if only by accident.
This is not even about systemd, it's a about libsystemd which is just a library for interfacing with systemd. You can have libsystemd installed and still don't have systemd itself installed. Debian has built some of their packages so that they depend on libsystemd, so installing them will bring libsystemd with them. Not a problem if you don't want to run systemd, but if you for some reason can't live with dpkg-query -l | grep systemd printing even a single line then this is apparently a problem.
those packages that i recompiled (policykit-1, d-bus, pulseaudio and util-linux) have a huge range of dependencies that cover something like 98% of the most commonly used software in the linux world. cups-daemon, the gimp, vlc, mplayer, and others too numerous to mention: all come under the fascist rule of libsystemd thanks to the unilateral decision making of a handful of people.
and i'll repeat it again because it seems not to be getting through: the problem is that there *is no alternative*. it's their way or fuck off: you are not permitted to argue your case even reasonably (because it will be ignored). and that's just... wholly unacceptable. *i don't care* who is techically right or wrong: i care that this is a situation that has become like the Microsoft Monopoly: dominate, dominate, dominate.
so that's the deadlock that i seek to break, by demonstrating that you *can* have a working desktop system without having a single part of the code written by people who do not listen and who act in such highly irresponsible ways.
In general, we already have a system that embraces many of the design principles observed in systemd and actually does a decent job of making the concepts work: Windows. Even with a great deal of talented investment over the course of decades, when a Windows system goes off the reservation in certain ways, no one will be able to bring it back because of how complicated the integration of the various components.
your post is particularly insightful - i hope it is recognised as such by moderators. i wanted to emphasise what you said, because NT 3.5 and 4.0 used a recursive login system based on DCE/RPC function calls. a "domain" logon was (is) actually no diffferent from a "local" logon: the only difference being that the SAM database was running locally (and was marked in the registry as being the same name as the machine). as a result of this, there were actually simple registry hacks for NT 3.51 to turn a workstation into a Primary Domain Controller!
so thanks to DCE/RPC, all that happened with a Domain Logon was that the incoming function call would make an (identical) recursive *outgoing* login function call to the nearest PDC/BDC/Trusted Domain. that Trusted Domain Controller would, in turn, on receipt of the incoming function call, make an (identical) recursive outgoing function call to the nearest PDC/BDC... and eventually, through this chain, the answer would be "login success or fail".
incredibly neat, and technically brilliant... but the actual number of people in the world who really truly understand that must be limited to under a hundred people at most. *not all of them* work at microsoft....
See, this is pretty much precisely my point. It's not that people's opinions are getting ignored. That happens all the time. It's that people aren't listening at all. And more to the point, that really critically important lessons of the past are being set aside merely because a small number of people have become convinced that they know a better way.
Again: in and of itself, that's not necessarily a problem. The problem here is that these particular people are wrong.
no, i disagree: i feel you pretty much nailed it but didn't realise it. the problem i feel really *is* that they're not listening... in combination with there being no alternative. if there was an alternative - a less disruptive one - then the fact that these key high-impact decisions were being made would *not matter*. why? because we would be able to use the alternatives and the people who were not listening could go screw themselves, and nobody would care.
it really *is* the fact that these people have such disproportionate influence and effect, and that they really *are* ramming "Their Way" down everyone's throats in such a cavalier way.
they may well perfectly be technically right (i have seen multiple analyses of systemd which indicate that they are not), but that *doesn't matter*, because it's the fact that they gave us no choice that is of far greater priority.
of all the arguments that i've seen, i have never seen one presented to the systemd team that gets this across to them clearly. the majority of arguments are either technical or abusive. it's only when you take a step back and think "what's really going on here"..
I agree, choice IS good. However, what I'm seeing so far is a bunch of vocal whiners on Slashdot bitching about systemd, and no one actually stepping up to make a distro that doesn't use it. So what it amounts to is a few loudmouths telling distro maintainers they're wrong, even though the loudmouths don't want to actually do any work on distros themselves.
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.
I personally prefer to use cross-platform software. I prefer software that runs about the same regardless of the platform I'm using it on, and I prefer to have the option to use any supported platform to run the software.
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.
Nearly every part of systemd beyond the minimal PID 1 functionality can be switched out with replacement components.
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!
Linux users are supposed to be more intelligent,
not everyone in the world is as intelligent as you or i, dude.
Man, can we just give this a rest? My gawd, I can't believe people have the energy for this. Just go back to an earlier distro before all this stuff and enjoy.
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.
So how do I upgrade an eoma standard system if no-one makes them?
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.
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.
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.
Assuming that the obsolete compute modules are of standard size/pinout (or, more likely, that compute chassis are only produced for phones that ship in sufficiently massive volume to assure a supply of board-donors), this scheme would work; but I have to imagine that a phone SoC would make a pretty dreadful compute node: Aside from being a bit feeble, there would be no reason for the interconnect to be anything but abysmal.
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:
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...
this is not a surprise. i have good 3d visual modelling ability, which allowed me to assess gaps between vehicles and drive at 30mph near curbs or bollards in width-restricted areas with an inch to spare either side, for example. i remember one day, a former partner and i, driving along a motorway. approximately fifty times throughout an hour-long journey, she would drive in the middle lane directly up to the back of a car in front at more than 15mph faster than the other vehicle, *apply the brakes* when the vehicle in front was only 8 to 10 metres away, and then and *only then* look in the side mirror to see if it was safe to change lane.
by contrast i would be constantly looking left, right and back (which is actually very tiring), would know where all vehicles were, even up to a mile away in either direction, and, using 3D modelling based on speeds and locations of other vehicles, would *predict* whether it was necessary for me to speed up or slow down in order to merge into faster (or slower) traffic in order to overtake vehicles *plural* in front. or, in some cases, whether to simply sit there happily at the speed of the vehicles in front.
now, this person - my former partner - drove an average of *four to five hours* per day like this. but if they are anything to go by, i am honestly and genuinely not surprised to hear that there are people who cannot judge distances, for whom the world is 2D, devoid of depth and the awareness that goes with it.
*that having been said*... the addition of "features" that apply the brakes without permission seem like an incredibly bad idea. i am reminded of a discussion recently... allow me to quote:
"We inadvertently built our own panic and short-sightedness into the very systems designed to protect us from our worst impulses"
then, also, there is the failure of the three laws of robotics (yes, asimov's work demonstrated that the three laws are an *outright failure*, not a success). the three laws basically provided robots that *prevented* humanity from taking risks. on a species-level, the three laws *terminated* our evolution and advancement.
so, honestly, i have to say that if people cannot have the good sense to be sufficiently aware when driving a 1500 kilogramme object that is capable of causing death to themselves and those in the immediate vicinity, then please, with much respect and love, give them family a darwin award, be glad that they weren't driving in *your* vicinity at the time, and be glad that our species gene pool's "average spacial awareness" capability just went up a tiny notch.
i pointed this out before, but google's policy of forcing people to give their *real* names is incredibly dangerous. google set themselves up as the *authority* - the guarantor - that the person you are contacting is exactly whom google *says* they are. now, given that it's possible under gmail to register very similar email addresses (with and without "." in them) we have the potential extremely litigous situation where someone could be deceived and then sue google - rightly - for damages based on google's guarantees - safety about identity - not being properly upheld.
contrast that situation where *everyone knows* that you don't trust email. or any kind of unconfirmed interaction on the internet.
and i think this is what people felt - subconsciously - both inside google as well as outside, that there was something very very badly wrong about forcing people to both disclose but also to allow google to "certify" their identity.
the other thing is just that... google+ is... simply... devoid of excitement and interest. it feels like it's a single-track uninspiring place, with one direction that Thou Shalt Go: google's waaaay.
contrast this to how facebook operates (or how myspace operated): i realise it's information-overload, but that's *precisely* what makes facebook (and made myspace) an interesting place to be. there are several ways to get to the same stuff.
strange as it may be for someone who is alarmed at the ease by which it is possible on facebook to track someone down merely from their first name (yes i met someone at a party, couldn't remember their surname, but managed to guess their approximate age, guessed that they must live in the approximate nearby area, then used the advanced search on facebook to find them... took a couple of weeks to work out i have to admit, and no i am *not* going to describe here on slashdot how it's done...)...... despite that, i have to say that there is actually something useful, and just generally more... homely about facebook than their is about *any* google products. google products are just... sterile and functional. you use gmail to send mail. you use google search to... well... search. but you use *facebook* to tell everyone you know that you wiped your arse today, and that's hilarious.
it also occurs to me: i wouldn't want to put personal stuff up on google: they might index it and let people search on it. and i think that's really the key, there. facebook is closed. you *have* to have a login. your personal stuff is *not* indexed publicly in search engines.
so, sorry google: you got it wrong on this one, and you can't be trusted, even if you said you'd get it right.
blind leading the blind, here, but my non-specialist-physics background might be a bit easier to understand than someone who mentions "QCD" at you. the way i understand it is that when you have particles around, they have E.M and gravitational fields, and they have binding forces and so on at the very-close (atomic) level which kiiinda mean that if you get close to them with another particle you either get sucked in, or banged away (like billiard balls) - actually _very_ much like billiar balls, in that you have to get *really* close in order for a deflection to occur [at all] but when you do you really know about it.
and, what we also know is that in non-vacuum there are *lots* of these particles. so, relatively speaking, even in a gas like any one particle really doesn't have to go that far to get banged-up by any other particle.
in other words, your average particle or your average photon (cosmic ray equals a photon with a very high energy content) has a huge amount of "resistance" applied to it, in *all* directions pretty much. this "resistance" means we end up with solid matter (ok gases too) that *stays* solid. stable. follows newton's laws and so on.
in empty space, there is *no such resistance*. there's nothing to get in the way, nothing to interfere with particles or rays. so even the smallest disturbance when two photons (cosmic rays) happen to cross paths, or one hits an atom, can result in "smaaashhh, wheeee!" any by-products of such collisions, which would normally be instantly destroyed by neighbouring particles, preciselybecause there *aren't* any neighbouring particles, the by-products get to stay alive for much longer [possibly forever].
so my take on this is that it's not so much that "empty space has energy", it's that empty space - by *being* empty - doesn't "resist" (so to speak) the creation process of particles. *scratches head*.... a bit like how if you have one extrovert in a party that's only just started, has huuge rooms, and nobody knows anyone else, the extrovert will stand in the middle of the room happily dancing and the very few other guests else will hug the walls, but if you have *lots* of extroverts in the room, then, well... it's just an another awesome party:)
throw-away comment, here:) i did a funny little bit of experimenting a couple of years back, when someone posted here an article about the density of deep space (the number of atoms per cubic metre) having been measured. anyway, remembering my o-level chemisty and i went, "hmm... that's interesting: i wonder if there's a relationship between that particle density and avogadro's constant.
so... i went... density = 7 * 10e-26, avogadro's const = 6.023 * 10e23, multiply the two together you get 4.2154. just for fun take the cube-root and oo! you get 1.6153982. now, to within experimental uncertainty of the measurements made of the density of deep space vacuum, that number should instantly be recogniseable +/- a bit, as the golden mean ratio (1.618 etc etc).
so we have a relationship - which has absolutely no quotes real quotes meaning whatsoever [ traditionally called "numerology" in a disparaging way in the physics community... ] between the density of particles in vacuum, avogadro's constant, and the golden mean ratio, in a formula that has very low kolmogorov complexity (https://en.wikipedia.org/wiki/Kolmogorov_complexity). which, as i do not have the kinds of hang-ups that the physics community has about these kinds of things, i find to be... beautiful.
and that's in and of itself enough for me. i don't care what the physicists say:)
anyway, as this is slashdot, i thought i'd happily derail the conversation with a nice bit of random semi-related nonsense, and see if anyone notices...
there is a problem with power in the EU - it's not properly earthed.
?
as in, the power sockets in the EU typically do not have an earth pin... at all. they are 2-pin, not 3-pin. so when i sit with my aluminium-cased laptop with my feet up on the radiator, not only does the WIFI stop working, and the SSD gets spiked, but i also get a mild electric shock.
You have to take steps to make progress. You can take something useful and make it more open (like librem) or you could start from scratch and make something very basic that is completely open.
You can take bigger strides towards openness and get something like Novena, but then you make other sacrifices (size, cost, performance).
I guess if you had infinite money you could make a high spec, completely opensource laptop.
interesting that you should say this:) i am taking a different approach. i am also developing a laptop where the goal is to reach FSF-Endorseability *and* high-end specs. i am doing it one phase at a time, as you suggest... however where instead of having infinite money i am instead using creativity and ingenuity (posh words for "persistent bloody-mindedness combined with desperation stroke eye-popping frustration").
sooo, i decided to go the "modular" route, but had to first create a decent hardware standard - one that will still be here in 10 years time but is simple enough for the average person (or a 5-year-old, or an 80-year-old) to use. it's based on an old "Memory Card" standard - you may have heard how PCMCIA is no longer being used? well, the case-work is still around:) so, re-using PCMCIA it is. and all the benefits of "Memory Card", you now get "Computer Card".. upgradeable, swappable, saleable, transferrable, storable "Computer" Card.... but then, of course, because of that, yaay, you now have to design entirely new casework, not just a motherboard. talking to casework suppliers didn't um go so well, so i have to do it. bought a mendel90 6 months ago...... but mendel90's don't do injection-moulded plastics, they do 3d-printed filament plastics. and when presented with a potential $USD 20,000 cost for creating injection-moulding (you send your STL files off, someone adapts them, CNCs out two steel halves and then a little *team* of chinese people sit there for weeks on end polishing out all the CNC burrs.... then you find out it's *completely wrong* and have *another* $USD 20,000 to pay... no wonder ODMs quote $USD 250,000 for developing laptops!!!)... anyway so that's all completely insane, so i thought, "hmm, i wonder if you can create reverse-3d-printed moulds to do injection-mould prototyping" and it turns out that you can. so i could at least - on a low budget - make a few runs out of very-low-temperature plastic (so as not to burst the 3d-printed plastic under pressure), hell i could even use plasticine for goodness sake, just to get a proof-of-concept, *then*.... and this is the hilarious bit.... there's a girl who's been doing LostPLA home-grown aluminium casting.... *using 1500W microwave ovens*:)
so in theory i could quite conceivably even try doing the casting of the inverse-moulds for plastic injection *myself*, out of landfill-designated aluminium bicycle rims. do watch that talk: julia is surprisingly subtly funny, there were lots of jokes that the audience didn't get (not a native english speaking audience), and a few later that they did.
bottom line it *can* be done... if you make the decision, and damn well stick at it until success. if you're interested to follow along, here's the links:
because people pay apple more money, so they can afford better designers and can get better components. [longer post explains more, see http://slashdot.org/~lkcl%5D
lenovo *used* to do this when they were IBM. IBM *used* to buy the more expensive components then run them at lower clockrates, which *used* to result in much more reliable products. the thermal stresses (even during normal operation) placed on ceramic packaging causes them to develop micro hairline cracks; high temperatures also cause migration of solder as well as the heavy metals within the silicon ICs themselves.
Slashdot Mirror
There are CONSTANT statements that if you do not use systemd you will not be able to use primary Linux distros in the future, because all software will supposedly be gobbled up by it as a dependency... To try and now make out like those dont exist is pretty silly.
not "supposedly" - *really*. if you run apt-rdepends -r libsystemd0 | a bit of awk | sort | uniq there are four *THOUSAND* five hundred packages that, if you were ever to do "apt-get --purge remove libsystemd0" you would NEVER be able to install. that's a whopping FIFTEEN PERCENT of the entire debian package repository that you are prevented and prohibited from installing, should you ever make the decision that you wish to keep libsystemd0 off of machines that you manage!
the reason for this insane level of *hard* dependency is because lennart pottering is both the developer of libsystemd0 *and* many other packages such as pulseaudio... so of *course* he decided that pulseaudio had to include - as a hard dependency - one of his projects, libsystemd0. libsdl likewise also uses it as a hard compile-time dependency, along with about 100 other applications and libraries.
those applications and libraries then quickly spread as further hard dependencies to include the gimp, apache2-dev, php5 (??!), erlang, libreoffice, cups, bluez/bluetooth (because of the links to pulseaudio), *all* the games that use libsdl (i.e. pretty much all of them), *all* the music software available for GNU/Linux (because of the link to pulseaudio), openjdk7, the eclipse IDE, apache tomcat, the android SDK, i mean.... the list is a _real_ eye-opener. you can review it here for yourself:
http://lkcl.net/reports/removi...
so yeah, not even _close_ to "supposedly", mate!
unix was supposed to be simple. systemd is an abortion and one that most of us do not want.
good to see this protest post with a hand-tweaked system; but the fact is, we should NOT have to flip over backwards to remove a stupid should-not-be-there-anyway daemon and its evil libs.
*thumbs-up* to both these things. thank you.
Really, someone should get a dictionary for their birthday and read the definition for "unilateral" lol.
that's in.... *counts on fingers*... 9? days? :)
ok so let's look it up... a random google search shows these:
1. Of, on, relating to, involving, or affecting only one side: "a unilateral advantage in defense" (New Republic).
2. Performed or undertaken by only one side: unilateral disarmament.
3. Obligating only one of two or more parties, nations, or persons, as a contract or an agreement.
4. Emphasizing or recognizing only one side of a subject.
5. Having only one side.
6. Tracing the lineage of one parent only: a unilateral genealogy.
7. Botany Having leaves, flowers, or other parts on one side only.
yep. definitions 1 through 5 are perfectly relevant. unilateral. meaning that pottering made the decision and (2) did not consult any of us. he claims to be "listening to users" yet (4) in fact ignores everything they tell him and carries on regardless. he has therefore violated the implicit software freedom contract (3) between users and developers who choose to be of service to others.
so yeah. it would appear that yes i really do know english, if only by accident.
This is not even about systemd, it's a about libsystemd which is just a library for interfacing with systemd. You can have libsystemd installed and still don't have systemd itself installed. Debian has built some of their packages so that they depend on libsystemd, so installing them will bring libsystemd with them. Not a problem if you don't want to run systemd, but if you for some reason can't live with dpkg-query -l | grep systemd printing even a single line then this is apparently a problem.
a *fraction* of the extent of the problem is actually illustrated here:
http://anfo.slavino.sk/libsyst...
those packages that i recompiled (policykit-1, d-bus, pulseaudio and util-linux) have a huge range of dependencies that cover something like 98% of the most commonly used software in the linux world. cups-daemon, the gimp, vlc, mplayer, and others too numerous to mention: all come under the fascist rule of libsystemd thanks to the unilateral decision making of a handful of people.
and i'll repeat it again because it seems not to be getting through: the problem is that there *is no alternative*. it's their way or fuck off: you are not permitted to argue your case even reasonably (because it will be ignored). and that's just... wholly unacceptable. *i don't care* who is techically right or wrong: i care that this is a situation that has become like the Microsoft Monopoly: dominate, dominate, dominate.
so that's the deadlock that i seek to break, by demonstrating that you *can* have a working desktop system without having a single part of the code written by people who do not listen and who act in such highly irresponsible ways.
In general, we already have a system that embraces many of the design principles observed in systemd and actually does a decent job of making the concepts work: Windows. Even with a great deal of talented investment over the course of decades, when a Windows system goes off the reservation in certain ways, no one will be able to bring it back because of how complicated the integration of the various components.
your post is particularly insightful - i hope it is recognised as such by moderators. i wanted to emphasise what you said, because NT 3.5 and 4.0 used a recursive login system based on DCE/RPC function calls. a "domain" logon was (is) actually no diffferent from a "local" logon: the only difference being that the SAM database was running locally (and was marked in the registry as being the same name as the machine). as a result of this, there were actually simple registry hacks for NT 3.51 to turn a workstation into a Primary Domain Controller!
so thanks to DCE/RPC, all that happened with a Domain Logon was that the incoming function call would make an (identical) recursive *outgoing* login function call to the nearest PDC/BDC/Trusted Domain. that Trusted Domain Controller would, in turn, on receipt of the incoming function call, make an (identical) recursive outgoing function call to the nearest PDC/BDC... and eventually, through this chain, the answer would be "login success or fail".
incredibly neat, and technically brilliant... but the actual number of people in the world who really truly understand that must be limited to under a hundred people at most. *not all of them* work at microsoft....
See, this is pretty much precisely my point. It's not that people's opinions are getting ignored. That happens all the time. It's that people aren't listening at all. And more to the point, that really critically important lessons of the past are being set aside merely because a small number of people have become convinced that they know a better way.
Again: in and of itself, that's not necessarily a problem. The problem here is that these particular people are wrong.
no, i disagree: i feel you pretty much nailed it but didn't realise it. the problem i feel really *is* that they're not listening... in combination with there being no alternative. if there was an alternative - a less disruptive one - then the fact that these key high-impact decisions were being made would *not matter*. why? because we would be able to use the alternatives and the people who were not listening could go screw themselves, and nobody would care.
it really *is* the fact that these people have such disproportionate influence and effect, and that they really *are* ramming "Their Way" down everyone's throats in such a cavalier way.
they may well perfectly be technically right (i have seen multiple analyses of systemd which indicate that they are not), but that *doesn't matter*, because it's the fact that they gave us no choice that is of far greater priority.
of all the arguments that i've seen, i have never seen one presented to the systemd team that gets this across to them clearly. the majority of arguments are either technical or abusive. it's only when you take a step back and think "what's really going on here"..
Can't someone fork a version without systemd?
I agree, choice IS good. However, what I'm seeing so far is a bunch of vocal whiners on Slashdot bitching about systemd, and no one actually stepping up to make a distro that doesn't use it. So what it amounts to is a few loudmouths telling distro maintainers they're wrong, even though the loudmouths don't want to actually do any work on distros themselves.
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.
I personally prefer to use cross-platform software. I prefer software that runs about the same regardless of the platform I'm using it on, and I prefer to have the option to use any supported platform to run the software.
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.
All or nothing?
for the average end-user or sysadmin? yes.
Nearly every part of systemd beyond the minimal PID 1 functionality can be switched out with replacement components.
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!
Linux users are supposed to be more intelligent,
not everyone in the world is as intelligent as you or i, dude.
Man, can we just give this a rest? My gawd, I can't believe people have the energy for this. Just go back to an earlier distro before all this stuff and enjoy.
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 it any different from a pc?
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.
So how do I upgrade an eoma standard system if no-one makes them?
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.
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.
Assuming that the obsolete compute modules are of standard size/pinout (or, more likely, that compute chassis are only produced for phones that ship in sufficiently massive volume to assure a supply of board-donors), this scheme would work; but I have to imagine that a phone SoC would make a pretty dreadful compute node: Aside from being a bit feeble, there would be no reason for the interconnect to be anything but abysmal.
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...
this is not a surprise. i have good 3d visual modelling ability, which allowed me to assess gaps between vehicles and drive at 30mph near curbs or bollards in width-restricted areas with an inch to spare either side, for example. i remember one day, a former partner and i, driving along a motorway. approximately fifty times throughout an hour-long journey, she would drive in the middle lane directly up to the back of a car in front at more than 15mph faster than the other vehicle, *apply the brakes* when the vehicle in front was only 8 to 10 metres away, and then and *only then* look in the side mirror to see if it was safe to change lane.
by contrast i would be constantly looking left, right and back (which is actually very tiring), would know where all vehicles were, even up to a mile away in either direction, and, using 3D modelling based on speeds and locations of other vehicles, would *predict* whether it was necessary for me to speed up or slow down in order to merge into faster (or slower) traffic in order to overtake vehicles *plural* in front. or, in some cases, whether to simply sit there happily at the speed of the vehicles in front.
now, this person - my former partner - drove an average of *four to five hours* per day like this. but if they are anything to go by, i am honestly and genuinely not surprised to hear that there are people who cannot judge distances, for whom the world is 2D, devoid of depth and the awareness that goes with it.
*that having been said*... the addition of "features" that apply the brakes without permission seem like an incredibly bad idea. i am reminded of a discussion recently... allow me to quote:
"We inadvertently built our own panic and short-sightedness into
the very systems designed to protect us from our worst impulses"
http://aeon.co/magazine/techno...
then, also, there is the failure of the three laws of robotics (yes, asimov's work demonstrated that the three laws are an *outright failure*, not a success). the three laws basically provided robots that *prevented* humanity from taking risks. on a species-level, the three laws *terminated* our evolution and advancement.
so, honestly, i have to say that if people cannot have the good sense to be sufficiently aware when driving a 1500 kilogramme object that is capable of causing death to themselves and those in the immediate vicinity, then please, with much respect and love, give them family a darwin award, be glad that they weren't driving in *your* vicinity at the time, and be glad that our species gene pool's "average spacial awareness" capability just went up a tiny notch.
i pointed this out before, but google's policy of forcing people to give their *real* names is incredibly dangerous. google set themselves up as the *authority* - the guarantor - that the person you are contacting is exactly whom google *says* they are. now, given that it's possible under gmail to register very similar email addresses (with and without "." in them) we have the potential extremely litigous situation where someone could be deceived and then sue google - rightly - for damages based on google's guarantees - safety about identity - not being properly upheld.
contrast that situation where *everyone knows* that you don't trust email. or any kind of unconfirmed interaction on the internet.
and i think this is what people felt - subconsciously - both inside google as well as outside, that there was something very very badly wrong about forcing people to both disclose but also to allow google to "certify" their identity.
the other thing is just that... google+ is... simply... devoid of excitement and interest. it feels like it's a single-track uninspiring place, with one direction that Thou Shalt Go: google's waaaay.
contrast this to how facebook operates (or how myspace operated): i realise it's information-overload, but that's *precisely* what makes facebook (and made myspace) an interesting place to be. there are several ways to get to the same stuff.
strange as it may be for someone who is alarmed at the ease by which it is possible on facebook to track someone down merely from their first name (yes i met someone at a party, couldn't remember their surname, but managed to guess their approximate age, guessed that they must live in the approximate nearby area, then used the advanced search on facebook to find them... took a couple of weeks to work out i have to admit, and no i am *not* going to describe here on slashdot how it's done...) ... ... despite that, i have to say that there is actually something useful, and just generally more... homely about facebook than their is about *any* google products. google products are just... sterile and functional. you use gmail to send mail. you use google search to... well... search. but you use *facebook* to tell everyone you know that you wiped your arse today, and that's hilarious.
it also occurs to me: i wouldn't want to put personal stuff up on google: they might index it and let people search on it. and i think that's really the key, there. facebook is closed. you *have* to have a login. your personal stuff is *not* indexed publicly in search engines.
so, sorry google: you got it wrong on this one, and you can't be trusted, even if you said you'd get it right.
Can anyone explain why empty space has energy?
blind leading the blind, here, but my non-specialist-physics background might be a bit easier to understand than someone who mentions "QCD" at you. the way i understand it is that when you have particles around, they have E.M and gravitational fields, and they have binding forces and so on at the very-close (atomic) level which kiiinda mean that if you get close to them with another particle you either get sucked in, or banged away (like billiard balls) - actually _very_ much like billiar balls, in that you have to get *really* close in order for a deflection to occur [at all] but when you do you really know about it.
and, what we also know is that in non-vacuum there are *lots* of these particles. so, relatively speaking, even in a gas like any one particle really doesn't have to go that far to get banged-up by any other particle.
in other words, your average particle or your average photon (cosmic ray equals a photon with a very high energy content) has a huge amount of "resistance" applied to it, in *all* directions pretty much. this "resistance" means we end up with solid matter (ok gases too) that *stays* solid. stable. follows newton's laws and so on.
in empty space, there is *no such resistance*. there's nothing to get in the way, nothing to interfere with particles or rays. so even the smallest disturbance when two photons (cosmic rays) happen to cross paths, or one hits an atom, can result in "smaaashhh, wheeee!" any by-products of such collisions, which would normally be instantly destroyed by neighbouring particles, preciselybecause there *aren't* any neighbouring particles, the by-products get to stay alive for much longer [possibly forever].
so my take on this is that it's not so much that "empty space has energy", it's that empty space - by *being* empty - doesn't "resist" (so to speak) the creation process of particles. *scratches head*. ... a bit like how if you have one extrovert in a party that's only just started, has huuge rooms, and nobody knows anyone else, the extrovert will stand in the middle of the room happily dancing and the very few other guests else will hug the walls, but if you have *lots* of extroverts in the room, then, well... it's just an another awesome party :)
throw-away comment, here :) i did a funny little bit of experimenting a couple of years back, when someone posted here an article about the density of deep space (the number of atoms per cubic metre) having been measured. anyway, remembering my o-level chemisty and i went, "hmm... that's interesting: i wonder if there's a relationship between that particle density and avogadro's constant.
so... i went... density = 7 * 10e-26, avogadro's const = 6.023 * 10e23, multiply the two together you get 4.2154. just for fun take the cube-root and oo! you get 1.6153982. now, to within experimental uncertainty of the measurements made of the density of deep space vacuum, that number should instantly be recogniseable +/- a bit, as the golden mean ratio (1.618 etc etc).
so we have a relationship - which has absolutely no quotes real quotes meaning whatsoever [ traditionally called "numerology" in a disparaging way in the physics community... ] between the density of particles in vacuum, avogadro's constant, and the golden mean ratio, in a formula that has very low kolmogorov complexity (https://en.wikipedia.org/wiki/Kolmogorov_complexity). which, as i do not have the kinds of hang-ups that the physics community has about these kinds of things, i find to be... beautiful.
and that's in and of itself enough for me. i don't care what the physicists say :)
anyway, as this is slashdot, i thought i'd happily derail the conversation with a nice bit of random semi-related nonsense, and see if anyone notices...
?
as in, the power sockets in the EU typically do not have an earth pin... at all. they are 2-pin, not 3-pin. so when i sit with my aluminium-cased laptop with my feet up on the radiator, not only does the WIFI stop working, and the SSD gets spiked, but i also get a mild electric shock.
is that clearer?
You have to take steps to make progress. You can take something useful and make it more open (like librem) or you could start from scratch and make something very basic that is completely open.
You can take bigger strides towards openness and get something like Novena, but then you make other sacrifices (size, cost, performance).
I guess if you had infinite money you could make a high spec, completely opensource laptop.
interesting that you should say this :) i am taking a different approach. i am also developing a laptop where the goal is to reach FSF-Endorseability *and* high-end specs. i am doing it one phase at a time, as you suggest... however where instead of having infinite money i am instead using creativity and ingenuity (posh words for "persistent bloody-mindedness combined with desperation stroke eye-popping frustration").
sooo, i decided to go the "modular" route, but had to first create a decent hardware standard - one that will still be here in 10 years time but is simple enough for the average person (or a 5-year-old, or an 80-year-old) to use. it's based on an old "Memory Card" standard - you may have heard how PCMCIA is no longer being used? well, the case-work is still around :) so, re-using PCMCIA it is. and all the benefits of "Memory Card", you now get "Computer Card".. upgradeable, swappable, saleable, transferrable, storable "Computer" Card. ... but then, of course, because of that, yaay, you now have to design entirely new casework, not just a motherboard. talking to casework suppliers didn't um go so well, so i have to do it. bought a mendel90 6 months ago... ... but mendel90's don't do injection-moulded plastics, they do 3d-printed filament plastics. and when presented with a potential $USD 20,000 cost for creating injection-moulding (you send your STL files off, someone adapts them, CNCs out two steel halves and then a little *team* of chinese people sit there for weeks on end polishing out all the CNC burrs.... then you find out it's *completely wrong* and have *another* $USD 20,000 to pay... no wonder ODMs quote $USD 250,000 for developing laptops!!!) ... anyway so that's all completely insane, so i thought, "hmm, i wonder if you can create reverse-3d-printed moulds to do injection-mould prototyping" and it turns out that you can. so i could at least - on a low budget - make a few runs out of very-low-temperature plastic (so as not to burst the 3d-printed plastic under pressure), hell i could even use plasticine for goodness sake, just to get a proof-of-concept, *then*.... and this is the hilarious bit.... there's a girl who's been doing LostPLA home-grown aluminium casting.... *using 1500W microwave ovens* :)
http://media.ccc.de/browse/con...
so in theory i could quite conceivably even try doing the casting of the inverse-moulds for plastic injection *myself*, out of landfill-designated aluminium bicycle rims. do watch that talk: julia is surprisingly subtly funny, there were lots of jokes that the audience didn't get (not a native english speaking audience), and a few later that they did.
bottom line it *can* be done... if you make the decision, and damn well stick at it until success. if you're interested to follow along, here's the links:
* micro-desktop (launching very soon) which has the first EOMA68 module: https://www.crowdsupply.com/eo...
* the 7in tablet (due to go to assembly this week) http://rhombus-tech.net/commun...
* the 15.6in laptop (currently developing the casework) http://rhombus-tech.net/commun...
on the laptop - as yo
because people pay apple more money, so they can afford better designers and can get better components. [longer post explains more, see http://slashdot.org/~lkcl%5D
lenovo *used* to do this when they were IBM. IBM *used* to buy the more expensive components then run them at lower clockrates, which *used* to result in much more reliable products. the thermal stresses (even during normal operation) placed on ceramic packaging causes them to develop micro hairline cracks; high temperatures also cause migration of solder as well as the heavy metals within the silicon ICs themselves.