[perl...] If they can understand that, they cannot understand anything.
dude. i am a software libre advocate and developer of 25 years experience. i've worked with million-line codebases for two decades. i have done reverse-engineering of ARM and x86 instructions. i've programmed PICs, Z80 and 68000 processors in assembler. i'm going to be working on designing and bringing to market a libre RISC-V SoC... and *I* do not want you to explain perl to me.
"Well, you see, that form is actually an instance of a subclass that inherits from that object which can be stored into that templated array thanks to polymorphism", then no more question from the non-programmer.
if you're looking for a way to justify your existence (as opposed to *genuinely* explaining what it is that you do to an outsider) then i would suggest prefacing that with, "i'm going to start at a high level. i'm then going to go into detail. my ability *to* go into detail is precisely why you employ me rather than someone who can do stuff with a spreadsheet. please feel free to stop me at any time when you have heard enough"
followed by going into detail and not stopping until they tell you to. when they've had enough, you can finish up with, "so do you now appreciate that this is far beyond the skill set of a lay person, to cope with this level of excruciating detail? i deal with it so that you don't have to. it's extremely challenging and tedious in a mind-numbing but extremely rewarding way for me, but only in that it's a massive challenge well achieved. can we please, therefore, in future, keep our conversations to the high-level requirements, and more than that, when i tell you that i *don't know how long something will take* please be patient and trust me to work through it until i know more, okay?"
if on the other hand they *genuinely* wish to know about programming, my favourite way to explain that is as follows:
okay, the idea is, you're going to give me a series of written instructions - a recipe - which i can give to absolutely any person, for them to follow in order to get from one corner of a tiled room to the other, negotiating around obstacles. that person will be BLINDFOLDED so that they only have a sense of touch in any direction of distance equal to ONE tile.
you then give them the following example:
step 1: go forward one step step 2: if you didn't bash into an obstacle, go to step 1 step 3: go right one step step 4: if you didn't bash into an obstacle, go to step 3 step 5: are you in the far corner? if yes HURRAH step 6: repeat from step 1
*we* know what the flaws are in that algorithm... but they won't. so, you LITERALLY get them to walk through it. as in, LITERALLY follow those instructions on a tiled kitchen floor. then you DELIBERATELY place obstacles so that they will get stuck, and ask them, "ok, so now how would you fix that?"
and when they go, "ahhh okaaay i get it. it's step-by-step stuff but you can get into trouble if you don't give the right instructions", then that really is the lightbulb moment for them in *truly* understanding the basics of programming. at *that* point you can explain to them that, unlike that very simple 6-step algorithm you write algorithms of TENS of THOUSANDS OF LINES every few months, and that the linux kernel is what... thirty MILLION lines or something insane, then they'll finally start to really and truly Get It.
if that's your boss they might even actually give you a payrise or at the very least treat you with a little more respect.
Please select from one of the following options: (1) Never Requires Encryption (2) Accept Encryption / Unencryption (3) Does not accept Unencrypted Data
the linux kernel - used in the majority of TVs, PVRs, STBs and Android devices - used to be at level (1). it's now moved to level (2). this is the "Green Light" for manufacturers to start producing HDMI devices at level (3). so tell me: in what way does this decision NOT reduce user freedom?
did... did the United States *really* just pass a law prohibiting American Citizens from being at liberty to choose precisely which software they wish to purchase and run? that appears to me to be an extremely dangerous precedent, and an extremely fascist thing to do, like the Nazis did in the 1930s: burning "unapproved" books. it would not surprise me if this same thought occurs to Civil Rights supporters and a case is taken up, fairly soon.
The BSDâ(TM)s and Illumos. There is no reason to use the tire fire that is Linux. You have options!
right. so the response is, if you have an extremely complex and comprehensive setup, which took years or possibly decades to establish and stabilise, with customised configurations, mission-critical services and much more, the response is: FUCK you, you stupid fucking twat, go fuck yourself and install BSD.
i'm deliberately over-exaggerating of course, but in doing so i'm highlighting that the linux distro community has, as a whole, betrayed an extremely important implicit trust placed in them, that you *do not* make massive underlying *NON-OPTIONAL* changes that force people into taking drastic, drastic action.
add http://angband.pl/debian/ to/etc/apt/sources.list before doing that and it will actually succeed. okok it's a bit more complex than that, but you can read the instructions online which are neeearly as simple:)
People who complain about systemd the most seem to have been using Linux for a very long time and just "don't want to change".
no, that's not it. people who have been using linux for a long time usually *know the corner-cases better*. in other words, they know *exactly* why it doesn't work and won't work, they know *exactly* the hell that it can and will create, under what circumstances, and they know *precisely* how they've been betrayed by the rail-roaded decisions made by distros without consulting them as to the complexities of the scenario to which they have been (successfully up until that point) deploying a GNU/Linux system.
also they've done the research - looked up systemd vs other init systems on the CVE mitre databases and gone "holy fuck".
also they've seen - perhaps even reported bugs themselves over the years - how well bugs are handled, and how reasonable and welcoming (or in some sad cases not, but generally it's ok) the developers are... then they've looked up the systemd bug database and how pottering abruptly CLOSES LEGITIMATE BUGREPORTS and they've gone "WHAT the fuck??"
also, they've been through the hell that was the "proprietary world", if they're REALLY old they've witnessed first-hand the "Unix Wars" and if they're not that old they experienced the domination of Windows through the 1990s. they know what a monoculture looks like and how dangerous that is for a computing eco-system.
in short, i have to apologise for pointing this out: they can read the danger signs far better than you can. sorry!:)
I don't think there's a problem with the idea of systemd. Having a standard way to handle process start-up, dependencies, failures, recovery, "contracts", etc... isn't a bad, or unique, thing -- Solaris has Service Manager, for example.
the difference is that solaris is - was - written and maintained by a single vendor. they have - had - the resources to keep it running, and you "bought in" to the sun microsystems (now oracle) way, and that was that. problems? pay oracle some money, get support... fixed.
free software is not *just* about a single way of doing things... because the single way doesn't fit absolutely *all* cases. take angstrom linux for example: an embedded version of GNU/Linux that doesn't even *have* an init system! you're expected to write your own initialisation system with hard-coded entries in/dev. why? because on an embedded system with only 32mb of RAM there *wasn't room* to run an init service.
then also we have freebsd and netbsd to consider, where security is much tighter and the team is smaller. in short: in the free software world unlike solaris there *is* no "single way" and any "single way" is guaranteed to be a nightmare pain-in-the-ass for at least somebody, somewhere.
this is what the "majority voting" that primarily debian - other distros less so because to some extent they have a narrower focus than debian - completely failed to appreciate. the "majority rule" decision-making, for all that it is blindly accepted to be "How Democracy Works" basically pissed in the faces of every debian sysadmin who has a setup that the "one true systemd way" does not suit - for whatever reason, where that reason ultimately DOES NOT MATTER, betraying an IMPLICIT trust placed by those extremely experienced users in the debian developers that you DO NOT fuck about with the underlying infrastructure without making it entirely optional.
now, it has to be said that the loss of several key debian developers, despite the incredible reasonable-ness of the way that they went about making their decision, made it clear to the whole debian team quite how badly they misjudged things: joey hess leaving with the declaration that debian's charter is a "toxic document" for example, and on that basis they have actually tried very hard to undo some of that damage.
the problem is that their efforts simply don't go far enough. udisk2, policykit, and several absolutely CRITICAL programs without which it is near flat-out impossible to run a desktop system - all gone. the only way to get those back is to add http://angband.pl/debian/ to/etc/apt/sources.list and use the (often out-of-date) nosystemd recompiled versions of packages that SHOULD BE A PERMANENT PART OF DEBIAN.
in essence: whilst debian developers are getting absolutely fed up of hearing about systemd, they need to accept that the voices that tell them that there is a problem - even though those voices cannot often actually quite say precisely what is wrong - are never, ever, going to stop, UNTIL the day that the role played by http://angband.pl/debian/ is absorbed into the main debian packaging, providing "Replaces / Provides / Conflicts" alternatives of pulseaudio, libcups, bsdutils, udev, util-linux, uuid-runtime, xserver-xorg and many more - all with a -nosystemd extension on the package name.
ONLY WHEN it is possible for debian users to run a debian system COMPLETELY free of everything associated with systemd - including libsystemd - will the utterly relentless voices and complaints stop, because only then, FINALLY, will people feel safer about running a debian system where there is absolutely NO possibility of harm, cost or inconvenience caused by the poisonous and utterly irresponsible attitude shown by pottering, with his blatant disregard for security, good design practices, and complete lack of respect for other peoples' valuable input by abruptly and irra
it turns out that, on arm embedded systems at the very least, where context-switching is a little slower and booting off of microsd cards results in amplification of any performance-related issues associated with drive reads/writes when compared to an SSD or HDD, sysvinit easily outperforms systemd for boot times.
That way you can be sure that if you download malware, it's not tampered with.
all it tells you is, the signature was valid. whilst it links the file *to* the signature, it doesn't tell you anything about the trustworthiness of the PERSON. for that, you need much much more than just a legitimate signature: you need a full web-of-trust and for the package uploaders to be involved in key-signing parties, where they've basically (collectively) staked their reputation on trusting the ACTUAL identity. this becomes incredibly hard to compromise when there are multiple people involved. nobody dares try to game such a system: it's a variant of the "prisoner's dilemma" except with a thousand or more people.
I use pip install all the time...well pip3 install
pypl is great but they could increase their security at bit and still keep the same level of functionality.
it's actually incredibly comprehensive and extremely involved. for a completely separate team, i'm just in the process of writing up the requirements (following software engineering practices) which cover exactly this scenario: you can read them here if you like (note: they're in development and undergoing review): http://lkcl.net/reports/wot/
basically from that MASSIVE list - a whopping EIGHTEEN separate and distinct requirements and that's not even getting into implementation details - you should be getting that familiar sinking feeling that what you're asking for is simply... too much for the pypi team to handle on their own. to expect them to be able to do a full verification of each and absolutely every single one of the packages - in fact to even keep their *own website* secure from attack - is simply too much.
what *would* work is if the pypi team told all uploaders that the entire pypi infrastructure is converting over to a secure web-of-trust: that it is now following standard best practices followed for decades now by absolutely every single distro. namely: that uploaders are required to engage in key-signing parties and to register in a web-of-trust; that uploaders must then digitally GPG-sign their packages; and that pypi will only authorise a package as being online in the pypi index when they have GPG-signed a SHA2 checksum of the complete and full listing of every single package available for download on the entire pypi site.
new package uploaders would then also need to be "approved" - it would need to become impossible for just any arbitrary-named package to be uploaded, as their GPG key would need to be verified as being part of the web-of-trust. this would then stop dead in its tracks the exact sort of thing that's come up (but also provide the level of trust and reassurance in every single package which is completely missing right now).
basically, pypi needs to follow the exact same standard practices as any GNU/Linux Distro, and, to be absolutely bluntly honest, anyone who downloads arbitrarily untrusted software (like they do with windows, and including people who use ubuntu and download arbitrary.deb files, bypassing the entire purpose of the GPG web-of-trust behind apt-get and aptitude), gets precisely and exactly what they deserve. yes i have had acquaintances who have blithely downloaded a trojan'ed.deb package because it happened to have the same name. no he didn't bother to check its provenance.
so, justin, may i respectfully recommend that if peace of mind is important to you, and you also wish to not have to do a full audit of the source code that you're downloading, that you use a GNU/Linux Distro only, and STOP using pip and pypi? if you're using a mac or using windows, you could at least have a mirror-machine where you do (if it's debian) "apt-get install python-mysqldb" or "apt-get source python-mysqldb" and then copy that over?
at least in that way you will save yourself some time but also you know that someone - somewhere has staked their public reputation and career on a very public declaration that they have at least done _some_ sort of checking on the source code that they have GPG-signed and uploaded into a distro's package repository. if it's too out-of-date or is just not included, *then* you can use pip or just grab the.tgz source archive for yourself, and do some sort of auditing.
all we have to do now is sit back and wait to hear that apple tracked down his phone id, then his phone, and bricked it for carrying out "unsanctioned" modifications...
does anyone else remember the "flagship US airforce carrier" that, back in the mid 1990s, had to be TOWED into harbour... because it was running Window NT 4.0 systems... which had just crashed across the *entire* ship? and does anyone else remember soldiers running Sony BMG Root-kitted CDs which then illegally sent out a listing of CLASSIFIED FILENAMES OFF TO SONY'S SERVERS?? do we not remember these things??
there is a *really good reason* why the NSA refuses to permit windows systems on its premises. why cannot the U.S. Military get it through its thick fucking head that running an OS that's been cost-shaved by a company that REFUSES TO LET ITS SECURITY TEAM MAKE CRITICAL CHANGES because the Security Director is told, every single fucking time "your proposed security improvement will cost us money. get lost and come back when you have a quotes security quotes fix that actually makes us some money".
we KNOW it's insecure. we KNOW it can be root-kitted (thank you NSA). we KNOW that there is ransomware and christ knows what else. so i don't understand why people do not understand that to run the Windows Operating System is tantamount to self-harm, and any Military that runs the Windows OS is basically, sad to say it, ASKING - no is DESPERATE - to be screwed over by anyone and everyone.
if it's a "secret" and highly specialist skillset it's likely to be for an H1B1 visa application "conform with the advertising in the USA so you can prove there were no applicants suitable" compliance. of course that is now completely messed up as they would be deluged with applicants by now...
this is basically what a very small team behind handhelds.org did with the openembedded project. bitbake - the build system behind openembedded - became an extremely powerful tool as a result, empowering that small team and part-time contributors to quite literally manage the build for something mad like over a hundred different hand-held devices... including some smartphones.
i don't exactly know the full history but i *think* that most of the team behind handhelds.org were employees of Compaq, and the employees weren't too happy that all of Compaq's PDAs ran Wince[ouch]. when Compaq lost interest in PDAs (even the ones with phone capability) thanks to the huge success of HTC's very first few phones like the Blueangel and Universal (a brilliant clamshell microlaptop in effect) it wasn't long before handhelds.org went down the tubes as well... which is a real serious pity. a *lot* of critical history - and source code - went down with it. i vaguely recall there being some sort of fight over the domain name... gaah this was all over 12 years ago now so it's all a bit fuzzy.
anyway, various... idiots since.... have lambasted bitbake and the entire openembedded project as quotes being too complex quotes and have come up with quotes simpler quotes systems such as buildroot. not realising that the complexity behind openembedded and bitbake is *there for a good reason*. along similar lines you end up with even more idiotic things like forking an entire distribution on a per-manufacturer basis, just as the OA describes.
the point is: it's a great idea for a small team to offer support for a wide range of devices, but they'll need appropriate infrastructure to do it. bitbake - and its ability to hybrid-combine python and shell-code with regular expression pattern-matching to manage toolchain downloading, toolchain compiling, patches, configuration, cross-compiling, cross-compiling using qemu to run the compilation and configuration "native" (yes, really! bitbake can run a native compiler via a qemu headless configuration in order to handle the proper cross-compiling of an entire OS!), parallel builds, cacheing and a bucket-load more, would be a good starting point for them. anything else - once you get into the details - quickly becomes a total nightmare, and that's what things like buildroot's developers totally fail to understand.
... the beauty of ASCII art is completely lost on the windows and macosx n00bs of yestercentury, what with all these GUI-based apps all using FUCKING VARIABLE WIDTH FONTS. *sigh*...
this is going to be interesting to watch. one of the world's best-informed advocates of software libre, who has studied the GPL for many years, versus some idiots who will have been ill-advised by some moron whose only saving grace is the indemnification insurance provided as a sop to corporate madness. for those people not familiar with what indemnification insurance is: it's where lawyers can basically get away with making fundamental errors, and the corporation to whom they give the advice can sue their company quite safely, *as long as they follow that advice*.
i really look forward to seeing how this turns out.
However, the sad truth is that it looks like there is no business case anymore
I'm not so sure. Yesterday, a female coworker showed me her Fairphone, then proceeded to completely disassemble it, right in front of my eyes. I couldn't contain my enthousiasm, but it was very remarkable. She told me she bought the phone then a couple of months in, dropped it and broke the screen. She ordered a new screen and replaced it herself.
take a deep breath... (and people with moderator rights: leave that "troll/flamebait -1" button alone please)... the problem with the fairphone has been that they've been massively ignorant of the consequences of software lock-in. yes, sure, great: they tackled the (hard) problem of "fair wages", and conflict minerals: these are things that any coop worth the "Fair Trade" salt would do, and it's good to see that they did it.... BUT....
for the first fairphone they did only that: tackle the "Fair Trade" concepts. people loved it. including various extremely prominent software libre developers and advocates. at first. we then warned them, "hang on a minute, you're going for 'Fair' but you've completely ignored the "UnFair-ness" of the proprietary operating system that you've bought - lock stock and binary-only GPL-violating criminally-infringing barrel from frickin MEDIATEK of all frickin people, and are about to get yourself into a shit-load of trouble when it comes to people wanting to upgrade. or fix security flaws".
response: absolutely f***-all from the Fairtrade team. so we stopped bothering to communicate with them, knowing that they (and their customers) would just have to experience the train-wreck for themselves....and what happens? *EXACTLY* as they were warned, customers 18 months down the line who were delighted to have bought the Fairphone 1 were getting REALLY PISSED OFF, feeling that they'd been totally deceived, when their requests for firmware upgrades to fix MAJOR known security vulnerabilities went completely unanswered.
why did those requests go unanswered? well... because AS THEY HAD BEEN WARNED, the chinese factory was under NDA with Mediatek (in direct violation of the GPL) and had *only* been given an illegal copyright-violating *BINARY ONLY* version of android (containing linux kernel source code and so also a second GPL violation). there *was* no source code, and there certainly weren't going to be any updates, at any time.
(btw note that because it has not obtained - and cannot obtain - the source code for the Fairphone 1, Fairphone is still in criminal infringement of Copyright law and has lost its rights to sell any products that use the linux kernel....)
now let's fast-forward to the Fairphone 2, which is now sold on the basis of its modularity. it's fantastic that it can be repaired, just as you say, cerberusss, but can the *OPERATING SYSTEM* be quotes repaired quotes?
if there's a massive security flaw like the one that left 900 hundred MILLION qualcomm--based devices completely vulnerable last year happens again, can the people who paid well north of $EUR 500 get it fixed immediately, rather than be at the mercy and whim of a company that ITSELF has *ABSOLUTELY NO CONTROL* over the software it's providing with the device that it's selling?
of course they cannot.
this is what michael is trying to get across to people. *it doesn't matter* even if you bought a "Fair" phone, with "Fair" hardware, and "Fair" wages, and "Fair terms for the workers" or anything else that's "Fair" if, just like *any other* device which is *not* under the "Fairtrade" brand you *still* have to chuck the whole fricking device into landfill because it became totally useless, virus-ridden and was instrumental in emptying your bank account, is it? that's not exactly "Fair", is it, ehn?:)
Slashdot Mirror
[perl...] If they can understand that, they cannot understand anything.
dude. i am a software libre advocate and developer of 25 years experience. i've worked with million-line codebases for two decades. i have done reverse-engineering of ARM and x86 instructions. i've programmed PICs, Z80 and 68000 processors in assembler. i'm going to be working on designing and bringing to market a libre RISC-V SoC... and *I* do not want you to explain perl to me.
"Well, you see, that form is actually an instance of a subclass that inherits from that object which can be stored into that templated array thanks to polymorphism", then no more question from the non-programmer.
if you're looking for a way to justify your existence (as opposed to *genuinely* explaining what it is that you do to an outsider) then i would suggest prefacing that with, "i'm going to start at a high level. i'm then going to go into detail. my ability *to* go into detail is precisely why you employ me rather than someone who can do stuff with a spreadsheet. please feel free to stop me at any time when you have heard enough"
followed by going into detail and not stopping until they tell you to. when they've had enough, you can finish up with, "so do you now appreciate that this is far beyond the skill set of a lay person, to cope with this level of excruciating detail? i deal with it so that you don't have to. it's extremely challenging and tedious in a mind-numbing but extremely rewarding way for me, but only in that it's a massive challenge well achieved. can we please, therefore, in future, keep our conversations to the high-level requirements, and more than that, when i tell you that i *don't know how long something will take* please be patient and trust me to work through it until i know more, okay?"
if on the other hand they *genuinely* wish to know about programming, my favourite way to explain that is as follows:
okay, the idea is, you're going to give me a series of written instructions - a recipe - which i can give to absolutely any person, for them to follow in order to get from one corner of a tiled room to the other, negotiating around obstacles. that person will be BLINDFOLDED so that they only have a sense of touch in any direction of distance equal to ONE tile.
you then give them the following example:
step 1: go forward one step
step 2: if you didn't bash into an obstacle, go to step 1
step 3: go right one step
step 4: if you didn't bash into an obstacle, go to step 3
step 5: are you in the far corner? if yes HURRAH
step 6: repeat from step 1
*we* know what the flaws are in that algorithm... but they won't. so, you LITERALLY get them to walk through it. as in, LITERALLY follow those instructions on a tiled kitchen floor. then you DELIBERATELY place obstacles so that they will get stuck, and ask them, "ok, so now how would you fix that?"
and when they go, "ahhh okaaay i get it. it's step-by-step stuff but you can get into trouble if you don't give the right instructions", then that really is the lightbulb moment for them in *truly* understanding the basics of programming. at *that* point you can explain to them that, unlike that very simple 6-step algorithm you write algorithms of TENS of THOUSANDS OF LINES every few months, and that the linux kernel is what... thirty MILLION lines or something insane, then they'll finally start to really and truly Get It.
if that's your boss they might even actually give you a payrise or at the very least treat you with a little more respect.
Please select from one of the following options:
(1) Never Requires Encryption
(2) Accept Encryption / Unencryption
(3) Does not accept Unencrypted Data
the linux kernel - used in the majority of TVs, PVRs, STBs and Android devices - used to be at level (1). it's now moved to level (2). this is the "Green Light" for manufacturers to start producing HDMI devices at level (3). so tell me: in what way does this decision NOT reduce user freedom?
well... if the research papers weren't in PAYWALLED journals then it would be possible for people to get at them and read them, wouldn't it? *sigh*...
Now two other posters, please verify me.
verified! now two...
"oh what a tangled web we weave...
when first...."
did... did the United States *really* just pass a law prohibiting American Citizens from being at liberty to choose precisely which software they wish to purchase and run? that appears to me to be an extremely dangerous precedent, and an extremely fascist thing to do, like the Nazis did in the 1930s: burning "unapproved" books. it would not surprise me if this same thought occurs to Civil Rights supporters and a case is taken up, fairly soon.
The BSDâ(TM)s and Illumos. There is no reason to use the tire fire that is Linux. You have options!
right. so the response is, if you have an extremely complex and comprehensive setup, which took years or possibly decades to establish and stabilise, with customised configurations, mission-critical services and much more, the response is: FUCK you, you stupid fucking twat, go fuck yourself and install BSD.
i'm deliberately over-exaggerating of course, but in doing so i'm highlighting that the linux distro community has, as a whole, betrayed an extremely important implicit trust placed in them, that you *do not* make massive underlying *NON-OPTIONAL* changes that force people into taking drastic, drastic action.
apt purge systemd
add http://angband.pl/debian/ to /etc/apt/sources.list before doing that and it will actually succeed. okok it's a bit more complex than that, but you can read the instructions online which are neeearly as simple :)
People who complain about systemd the most seem to have been using Linux for a very long time and just "don't want to change".
no, that's not it. people who have been using linux for a long time usually *know the corner-cases better*. in other words, they know *exactly* why it doesn't work and won't work, they know *exactly* the hell that it can and will create, under what circumstances, and they know *precisely* how they've been betrayed by the rail-roaded decisions made by distros without consulting them as to the complexities of the scenario to which they have been (successfully up until that point) deploying a GNU/Linux system.
also they've done the research - looked up systemd vs other init systems on the CVE mitre databases and gone "holy fuck".
also they've seen - perhaps even reported bugs themselves over the years - how well bugs are handled, and how reasonable and welcoming (or in some sad cases not, but generally it's ok) the developers are... then they've looked up the systemd bug database and how pottering abruptly CLOSES LEGITIMATE BUGREPORTS and they've gone "WHAT the fuck??"
also, they've been through the hell that was the "proprietary world", if they're REALLY old they've witnessed first-hand the "Unix Wars" and if they're not that old they experienced the domination of Windows through the 1990s. they know what a monoculture looks like and how dangerous that is for a computing eco-system.
in short, i have to apologise for pointing this out: they can read the danger signs far better than you can. sorry! :)
I don't think there's a problem with the idea of systemd. Having a standard way to handle process start-up, dependencies, failures, recovery, "contracts", etc... isn't a bad, or unique, thing -- Solaris has Service Manager, for example.
the difference is that solaris is - was - written and maintained by a single vendor. they have - had - the resources to keep it running, and you "bought in" to the sun microsystems (now oracle) way, and that was that. problems? pay oracle some money, get support... fixed.
free software is not *just* about a single way of doing things... because the single way doesn't fit absolutely *all* cases. take angstrom linux for example: an embedded version of GNU/Linux that doesn't even *have* an init system! you're expected to write your own initialisation system with hard-coded entries in /dev. why? because on an embedded system with only 32mb of RAM there *wasn't room* to run an init service.
then also we have freebsd and netbsd to consider, where security is much tighter and the team is smaller. in short: in the free software world unlike solaris there *is* no "single way" and any "single way" is guaranteed to be a nightmare pain-in-the-ass for at least somebody, somewhere.
this is what the "majority voting" that primarily debian - other distros less so because to some extent they have a narrower focus than debian - completely failed to appreciate. the "majority rule" decision-making, for all that it is blindly accepted to be "How Democracy Works" basically pissed in the faces of every debian sysadmin who has a setup that the "one true systemd way" does not suit - for whatever reason, where that reason ultimately DOES NOT MATTER, betraying an IMPLICIT trust placed by those extremely experienced users in the debian developers that you DO NOT fuck about with the underlying infrastructure without making it entirely optional.
now, it has to be said that the loss of several key debian developers, despite the incredible reasonable-ness of the way that they went about making their decision, made it clear to the whole debian team quite how badly they misjudged things: joey hess leaving with the declaration that debian's charter is a "toxic document" for example, and on that basis they have actually tried very hard to undo some of that damage.
the problem is that their efforts simply don't go far enough. udisk2, policykit, and several absolutely CRITICAL programs without which it is near flat-out impossible to run a desktop system - all gone. the only way to get those back is to add http://angband.pl/debian/ to /etc/apt/sources.list and use the (often out-of-date) nosystemd recompiled versions of packages that SHOULD BE A PERMANENT PART OF DEBIAN.
in essence: whilst debian developers are getting absolutely fed up of hearing about systemd, they need to accept that the voices that tell them that there is a problem - even though those voices cannot often actually quite say precisely what is wrong - are never, ever, going to stop, UNTIL the day that the role played by http://angband.pl/debian/ is absorbed into the main debian packaging, providing "Replaces / Provides / Conflicts" alternatives of pulseaudio, libcups, bsdutils, udev, util-linux, uuid-runtime, xserver-xorg and many more - all with a -nosystemd extension on the package name.
ONLY WHEN it is possible for debian users to run a debian system COMPLETELY free of everything associated with systemd - including libsystemd - will the utterly relentless voices and complaints stop, because only then, FINALLY, will people feel safer about running a debian system where there is absolutely NO possibility of harm, cost or inconvenience caused by the poisonous and utterly irresponsible attitude shown by pottering, with his blatant disregard for security, good design practices, and complete lack of respect for other peoples' valuable input by abruptly and irra
it turns out that, on arm embedded systems at the very least, where context-switching is a little slower and booting off of microsd cards results in amplification of any performance-related issues associated with drive reads/writes when compared to an SSD or HDD, sysvinit easily outperforms systemd for boot times.
https://xkcd.com/1420/
"Internet"!
censored!
"Freedom"!
"we did it to ourselves!"
You cannot tolerate your president trying to build a power structure outside the one constrained by your Constitution unless you WANT a dictatorship.
well... according to the system utilised - known to be THE weakest form of government ever invented (democracy) - the citizens of the united states *do* want him in and thus *have* trusted him to make the right decisions for the four years of his term of office and thus *do* want a dictatorship oh hang on... https://politics.slashdot.org/... https://tech.slashdot.org/stor... https://news.slashdot.org/stor... https://yro.slashdot.org/story... https://politics.slashdot.org/...
And how would cryptographically signed even help?
That way you can be sure that if you download malware, it's not tampered with.
all it tells you is, the signature was valid. whilst it links the file *to* the signature, it doesn't tell you anything about the trustworthiness of the PERSON. for that, you need much much more than just a legitimate signature: you need a full web-of-trust and for the package uploaders to be involved in key-signing parties, where they've basically (collectively) staked their reputation on trusting the ACTUAL identity. this becomes incredibly hard to compromise when there are multiple people involved. nobody dares try to game such a system: it's a variant of the "prisoner's dilemma" except with a thousand or more people.
I use pip install all the time...well pip3 install
pypl is great but they could increase their security at bit and still keep the same level of functionality.
it's actually incredibly comprehensive and extremely involved. for a completely separate team, i'm just in the process of writing up the requirements (following software engineering practices) which cover exactly this scenario: you can read them here if you like (note: they're in development and undergoing review): http://lkcl.net/reports/wot/
basically from that MASSIVE list - a whopping EIGHTEEN separate and distinct requirements and that's not even getting into implementation details - you should be getting that familiar sinking feeling that what you're asking for is simply... too much for the pypi team to handle on their own. to expect them to be able to do a full verification of each and absolutely every single one of the packages - in fact to even keep their *own website* secure from attack - is simply too much.
what *would* work is if the pypi team told all uploaders that the entire pypi infrastructure is converting over to a secure web-of-trust: that it is now following standard best practices followed for decades now by absolutely every single distro. namely: that uploaders are required to engage in key-signing parties and to register in a web-of-trust; that uploaders must then digitally GPG-sign their packages; and that pypi will only authorise a package as being online in the pypi index when they have GPG-signed a SHA2 checksum of the complete and full listing of every single package available for download on the entire pypi site.
new package uploaders would then also need to be "approved" - it would need to become impossible for just any arbitrary-named package to be uploaded, as their GPG key would need to be verified as being part of the web-of-trust. this would then stop dead in its tracks the exact sort of thing that's come up (but also provide the level of trust and reassurance in every single package which is completely missing right now).
basically, pypi needs to follow the exact same standard practices as any GNU/Linux Distro, and, to be absolutely bluntly honest, anyone who downloads arbitrarily untrusted software (like they do with windows, and including people who use ubuntu and download arbitrary .deb files, bypassing the entire purpose of the GPG web-of-trust behind apt-get and aptitude), gets precisely and exactly what they deserve. yes i have had acquaintances who have blithely downloaded a trojan'ed .deb package because it happened to have the same name. no he didn't bother to check its provenance.
so, justin, may i respectfully recommend that if peace of mind is important to you, and you also wish to not have to do a full audit of the source code that you're downloading, that you use a GNU/Linux Distro only, and STOP using pip and pypi? if you're using a mac or using windows, you could at least have a mirror-machine where you do (if it's debian) "apt-get install python-mysqldb" or "apt-get source python-mysqldb" and then copy that over?
at least in that way you will save yourself some time but also you know that someone - somewhere has staked their public reputation and career on a very public declaration that they have at least done _some_ sort of checking on the source code that they have GPG-signed and uploaded into a distro's package repository. if it's too out-of-date or is just not included, *then* you can use pip or just grab the .tgz source archive for yourself, and do some sort of auditing.
all we have to do now is sit back and wait to hear that apple tracked down his phone id, then his phone, and bricked it for carrying out "unsanctioned" modifications...
does anyone else remember the "flagship US airforce carrier" that, back in the mid 1990s, had to be TOWED into harbour... because it was running Window NT 4.0 systems... which had just crashed across the *entire* ship? and does anyone else remember soldiers running Sony BMG Root-kitted CDs which then illegally sent out a listing of CLASSIFIED FILENAMES OFF TO SONY'S SERVERS?? do we not remember these things??
there is a *really good reason* why the NSA refuses to permit windows systems on its premises. why cannot the U.S. Military get it through its thick fucking head that running an OS that's been cost-shaved by a company that REFUSES TO LET ITS SECURITY TEAM MAKE CRITICAL CHANGES because the Security Director is told, every single fucking time "your proposed security improvement will cost us money. get lost and come back when you have a quotes security quotes fix that actually makes us some money".
we KNOW it's insecure. we KNOW it can be root-kitted (thank you NSA). we KNOW that there is ransomware and christ knows what else. so i don't understand why people do not understand that to run the Windows Operating System is tantamount to self-harm, and any Military that runs the Windows OS is basically, sad to say it, ASKING - no is DESPERATE - to be screwed over by anyone and everyone.
if it's a "secret" and highly specialist skillset it's likely to be for an H1B1 visa application "conform with the advertising in the USA so you can prove there were no applicants suitable" compliance. of course that is now completely messed up as they would be deluged with applicants by now...
call that a fish war?? https://www.youtube.com/watch?... now that's what i call a fish war...
this is basically what a very small team behind handhelds.org did with the openembedded project. bitbake - the build system behind openembedded - became an extremely powerful tool as a result, empowering that small team and part-time contributors to quite literally manage the build for something mad like over a hundred different hand-held devices... including some smartphones.
i don't exactly know the full history but i *think* that most of the team behind handhelds.org were employees of Compaq, and the employees weren't too happy that all of Compaq's PDAs ran Wince[ouch]. when Compaq lost interest in PDAs (even the ones with phone capability) thanks to the huge success of HTC's very first few phones like the Blueangel and Universal (a brilliant clamshell microlaptop in effect) it wasn't long before handhelds.org went down the tubes as well... which is a real serious pity. a *lot* of critical history - and source code - went down with it. i vaguely recall there being some sort of fight over the domain name... gaah this was all over 12 years ago now so it's all a bit fuzzy.
anyway, various... idiots since.... have lambasted bitbake and the entire openembedded project as quotes being too complex quotes and have come up with quotes simpler quotes systems such as buildroot. not realising that the complexity behind openembedded and bitbake is *there for a good reason*. along similar lines you end up with even more idiotic things like forking an entire distribution on a per-manufacturer basis, just as the OA describes.
the point is: it's a great idea for a small team to offer support for a wide range of devices, but they'll need appropriate infrastructure to do it. bitbake - and its ability to hybrid-combine python and shell-code with regular expression pattern-matching to manage toolchain downloading, toolchain compiling, patches, configuration, cross-compiling, cross-compiling using qemu to run the compilation and configuration "native" (yes, really! bitbake can run a native compiler via a qemu headless configuration in order to handle the proper cross-compiling of an entire OS!), parallel builds, cacheing and a bucket-load more, would be a good starting point for them. anything else - once you get into the details - quickly becomes a total nightmare, and that's what things like buildroot's developers totally fail to understand.
... the beauty of ASCII art is completely lost on the windows and macosx n00bs of yestercentury, what with all these GUI-based apps all using FUCKING VARIABLE WIDTH FONTS. *sigh*...
this is going to be interesting to watch. one of the world's best-informed advocates of software libre, who has studied the GPL for many years, versus some idiots who will have been ill-advised by some moron whose only saving grace is the indemnification insurance provided as a sop to corporate madness. for those people not familiar with what indemnification insurance is: it's where lawyers can basically get away with making fundamental errors, and the corporation to whom they give the advice can sue their company quite safely, *as long as they follow that advice*.
i really look forward to seeing how this turns out.
However, the sad truth is that it looks like there is no business case anymore
I'm not so sure. Yesterday, a female coworker showed me her Fairphone, then proceeded to completely disassemble it, right in front of my eyes. I couldn't contain my enthousiasm, but it was very remarkable. She told me she bought the phone then a couple of months in, dropped it and broke the screen. She ordered a new screen and replaced it herself.
take a deep breath... (and people with moderator rights: leave that "troll/flamebait -1" button alone please)... the problem with the fairphone has been that they've been massively ignorant of the consequences of software lock-in. yes, sure, great: they tackled the (hard) problem of "fair wages", and conflict minerals: these are things that any coop worth the "Fair Trade" salt would do, and it's good to see that they did it. ... BUT....
for the first fairphone they did only that: tackle the "Fair Trade" concepts. people loved it. including various extremely prominent software libre developers and advocates. at first. we then warned them, "hang on a minute, you're going for 'Fair' but you've completely ignored the "UnFair-ness" of the proprietary operating system that you've bought - lock stock and binary-only GPL-violating criminally-infringing barrel from frickin MEDIATEK of all frickin people, and are about to get yourself into a shit-load of trouble when it comes to people wanting to upgrade. or fix security flaws".
response: absolutely f***-all from the Fairtrade team. so we stopped bothering to communicate with them, knowing that they (and their customers) would just have to experience the train-wreck for themselves. ...and what happens? *EXACTLY* as they were warned, customers 18 months down the line who were delighted to have bought the Fairphone 1 were getting REALLY PISSED OFF, feeling that they'd been totally deceived, when their requests for firmware upgrades to fix MAJOR known security vulnerabilities went completely unanswered.
why did those requests go unanswered? well... because AS THEY HAD BEEN WARNED, the chinese factory was under NDA with Mediatek (in direct violation of the GPL) and had *only* been given an illegal copyright-violating *BINARY ONLY* version of android (containing linux kernel source code and so also a second GPL violation). there *was* no source code, and there certainly weren't going to be any updates, at any time.
(btw note that because it has not obtained - and cannot obtain - the source code for the Fairphone 1, Fairphone is still in criminal infringement of Copyright law and has lost its rights to sell any products that use the linux kernel....)
now let's fast-forward to the Fairphone 2, which is now sold on the basis of its modularity. it's fantastic that it can be repaired, just as you say, cerberusss, but can the *OPERATING SYSTEM* be quotes repaired quotes?
if there's a massive security flaw like the one that left 900 hundred MILLION qualcomm--based devices completely vulnerable last year happens again, can the people who paid well north of $EUR 500 get it fixed immediately, rather than be at the mercy and whim of a company that ITSELF has *ABSOLUTELY NO CONTROL* over the software it's providing with the device that it's selling?
of course they cannot.
this is what michael is trying to get across to people. *it doesn't matter* even if you bought a "Fair" phone, with "Fair" hardware, and "Fair" wages, and "Fair terms for the workers" or anything else that's "Fair" if, just like *any other* device which is *not* under the "Fairtrade" brand you *still* have to chuck the whole fricking device into landfill because it became totally useless, virus-ridden and was instrumental in emptying your bank account, is it? that's not exactly "Fair", is it, ehn? :)