Are we talking theoretically, or are we talking practically? Because practically there are many choices out there for a cheap laptop that is capable of running arbitrary code.
Cheap : yes. But cheap isn't the only characteristic that attract people to chromebooks. The form factor is also another reason.
And most of the "run arbitrary code, and easily install Linux on them" devices tend to be heavy clunky workstation-class laptops (again for obious market reasons : most linux users tend to be developers, its best to concentrate effort to create pro-laptops catering to them)
Chrome books tend to be extremely light and thin.
If you're on the market of a machine which doesn't break your back, and for which you hope to get supported drivers you best bets are in order : ChromeBooks then Windows ultraportable. Usually, forget about MacBook Air, their weird embed controller won't get driver support quickly.
And that's for ulta-thin portable.
Then there are smartphone. There it's very hard to find device allowing end-users to install arbitrary code. Usually you'll find it only on special hobbyist-oriented platforms, which tend to be expensive and with lower hardware specs (due to smaller production runs) like OpenMoko/GoldeDelicious FreeRunner/GTA04, like Pyra handheld console, etc.
There are a few consumer-oriented platforms that can optionally allow you to run arbitrary code : the above mentionned Jolla 1 by the former sacked R&D team of Nokia, Palm / HP's Pre (and the tendency has now halted, after switching hands to LG), etc.
And in between (still a smaller production run and a bit expensive for not-stellar specs. But more consumer-oriented than hobbyist oriented) : Fairphone 2.
Both cgroups and containers can be created and manipulated from the command line. Nobody bothered to do this as a PoC before going off on a tear and creating systemd.
There were command-line demos of cgroup/namespace (video of devs launching "make -j 255" while the desktop remains responsive).
What nobody bothered, is trying to rewrite the mass amount of bash script to support it. (Specially since nearly every distro seems to write their own script madness to handle starting/stopping jobs *).
You would either need each single distro to rewrite mass amount of in-house developed shell code in order to leverage such newer kernel functionnality. Or, you need that a few standard component that leverage the facility for you an simplify using it. For obvious resource-saving reasons, most people went for the 2nd option. Systemd was one of such developed facilities, and is the one who ended up the most popular. (By redhat who developed it. But also by other distributions who picked it up very early like suse). And as usual, Canonical went for their own "NIH-syndrom" solution (upstart), before eventually joining everyone else.
---
* : which is another advantage of systemd. Most distribution wrote their own rc?.d scripts, usually with tons of boiler-plate code (for starting, checking status, etc.) systemd relies on much smaller simpler static configuration files - easier to edit, also easier to share. It's easier to maintain the the content of rc?d.
On the other hand, unlike SysVInit, where much of their processing is done by calling bash (i.e.: outside of PID 1), systemd move a little bit more functionality in there (into PID 1) in order to be able to interpret the conf files.
It is also for variable random content. Imagine a service that returns a webpage containing the product (of the multiplication) of two numbers, followed by a list of links to ten other random number pairs you could try. It would take a 1kB page to write, but infinite space to archive *all* the results
And archive.org already has a correct behaviour for that : - it wont try to download all infinity of solution in one go (e.g.: generating giga-byte worth of data out of the 1kB Perl/PHP/NodeJS/whatever source) - instead it will occasionally rescan the page, every few days (more or less frequently, depending on popularity of the links) It provides a small glimpse of what a user could have seen back then on the website.
By the way, back in the 2000s, this was exactly a popular way to poison SPAM robots spiders who where scanning the web for e-mail addresses. - Either they honour robots and not scan that or any other sources of e-mail on the site. - Or they attempt to ignore robots.txt and follow links they aren't authorised to, and end-up siphonning giga-bytes worth bogus e-mails addresses auto-generated by small perl script, which will pollute their base of harvested addresses.
Archive.org's spider might by a tiny bit more susceptible to this kind of things. Bot as much as a SPAM email-harvesting spider (which will try to download as much as possible, much more aggressively than archive.org), but still such a labyrinth of links might get archive lost.
So no, this will not meet your needs. And that's OK, because not every product needs to be for Slashdot readers to use directly.
But on the other hand there are users who DO need such product. If manufacturers only produce device that cater only to the most popular users, this is going to be problematic. Because nobody will produce any product that could also fill the needs of less common users.
On the otherhand, manuacturer could produce device that could, if the user is motivated enough, be converted to the needs of more peculiar users (e.g.: how easy it is to switch on developer mode on Jolla, and older HP / Palm smartphones), you end up with a device that is both cheap and mass-produced, but also can be coerced to fullfill the needs of a few atypical users who'll otherwise be left in the dust.
But do these "separate application[s]" break if pid 1 is something other than systemd?
Depends on the applications.
Boot-loader ? NTP clients ? these aren't deeply interdependent. You could very much use these and then run openrc if you want. These are just handled by systemd in the sens that these are program who are now developed by people who are on the systemd *project* team. At most systemd might leverage boot-loader in the sense that it can more easily send parameters to it for the next boot.
Though other daemon might be much more interlinked with systemd's (the daemon running at PID 1) job of starting/stopping things. (I'm thinking about daemon managing seats, sessions, and starting/stopping hardware).
These are important as over time, the Linux kernel is starting to go way much more advanced than standard POSIX behaviour. Linux kernel, for example, offers cgroup isolation, namespaces, etc. (the facilities which are leveraged by containers such as LXC, Docker, Andbox...) which are definitely useful (separating session in different name-spaces, jailing some daemons in containers, automatically configuring the content of a container state-lessly) The older bash-script-based mess of code that used to predate systemd has absolutely zero ability to leverage them. SystemD is one rather successful way to deal with those things that wasn't provided by SysVinit.
Having trouble affording holiday accommodation, than buy a bloody tent, no hotels in areas zoned residential only and huge fines for those who attempt to break those planning laws.
In other countries (e.g.: France), renting apartment is considered pretty normal whereas you deffinitely aren't free to put your tent anywhere else except is a few designated camping area (that you must pay, and make reservations in advance).
Thus AirBnB-like service are considered pretty much normal there and have been exist long before (all the way back to the minitel-era)
In other country (e.g.: France) on-line systems for people renting out their appartment - all the way to small hotel-like family-operated business - have existed for ages without any problems.
As such technologies started to appear (in France : all the way back to minitels) society and legislation simply adapted to it.
a.k.a. "OMG, a few assistive tools that simplify driving(*) aren't actually a electronic horse (or donkey) that can bring me home safely even if I sleep the whole way through ?"
How this lawsuit has any merit ? Had this been filed in Europe, the lawyers and plaintiff would had been laughed away of the court room.
OTOH, similar kind of technology has been available on car of European manufacturer for quite some time (random examples: Volvo, Mercedes), and is an absolute standard with some constructors (example: VW. You can't buy even the smallest VW Up! without at least a LIDAR for in-city use).
And I haven't read anywhere of a lawsuit filed in Europe pretending that such things are a dangerous technology. It's just tools to help. The driver is still in charge and shouldn't shut down their brain.
(And for the record, taking an innocent bystander with you when killing yourself by sheer stupidity will disqualify you from the Darwin Award)
---
(*) BTW: exactly what the word "Auto-pilot" refers to in any other field : aviation, navigation, etc. only in the mind of a few stupid users does it mean "an electronic donkey that brings me home while I'm passed out after the bar closes"
My Subaru has an electric parking brake (my wife wanted it). I can't figure out what's wrong with a mechanical parking brake.
For a plain simple old car, an electric parking brake only makes sense for one single element : - pulling it up is easier because it's not you exerting the actual force on the brake, but the brake's electrical motor. If your wife doesn't have that much hand force to the point that pulling the lever is cumbersome, an electrical brake makes it much simpler to use. (Push the button instead of try to pull the lever)
For a modern car filled with electronics, it's an entirely different wolrd of possibility : now the car can decide to put or lift the parking brake it self, and thus the car can automatically do it when needed. - It can automatically engage it when you lock the car, and disengage when you start driving, no button push even needed. - the adaptive cruise control or automatic parking can correctly use the parking brake on street with steep slope. (e.g.: the car arrives at a waiting queue in front of a red light on a upward going street. the correct procedure would be to engage the parking brake when you stand still, and disengage when starting to drive again so the cars doesn't roll back a bit while you maneuver the pedals (clutch/brake/accelerator). When using adaptive cruise control and an electric brake, the car does everything on its own - at least the car I've driven).
TFA's being Teslas, and Elon Musk being big on autopilot assisting (the latest software does also park automatically, and has been doing adaptive cruise control for a couple of versions) - I guess in this case it's the later : enabling the car to autonomously use the parking break in corresponding maneuvers. Though, this being an electric drive, there aren't any clutch or gearbox to play with, so I doubt the maneuvres are the same)
Actually, they're one of the copy-cat companies which jumped on the idea when the originating company published their idea. That company is still alive, though struggling. The biggest setback was chips. You're supposed to pay using your chip now, swiping is reserved for the restroom. These multi-card cards don't have chips.
Some do. The idea is that you're not trying to *copy* the data from the source card's chip to the multicard's chip. The mutlicard's chip has it's own private credential on the chip. What you do is you register said credential as yet another acceptable ID at the other company. (So the company isn't accepting only info of Card A - that also got copied on card B. But the company is accepting any of the private key on the chips of either card A or card B). I can open a shared car with my train pass, because the carsharing company accepts to recognize the train pass as also identifying me.
This concept has been popular for ages for ski passes across european ski resorts : nearly all companies accept each others wireless cards (to the point that it even ended up in wrist watches).
That's why 'plastic' could never mimic a chip card; because to mimic the behaviour and 'signing capabilities' of such a card would require knowing that secret information along with associated algorithms
Or, inversely, it could hold its own sets of secret information, and the plastc compagny would register these as an acceptable form of ID / as altenate accepted signing to the other companies.
(I.e.: when you "copy" a credit card or an access card to it, what actually goes behind the curtain, is that in the DB of the bank or some other company the plastc is added as yet another accepted form of ID for you next to whatever contactless card / RFID fob you were already using).
At lest that's how it is actuallyimplemented in the realworld by other companies that didn't go bust like plastc.
Granted, it doesn't change anything in your scenario, but given European chip 'n pin do connect, I doubt you attack would be feasible (ignoring the fact you need a 1000 unconnected terminals, which is doing to be very hard to find).
That attack would definitely be feasible. *BUT* the unconnected terminals would be limited to a small amount only. So at the end of the day, the bank only loses a couple of thousands of EUR, (Well within something they can live with) or bounces the transaction back and a thousands of shops are a few dozens bucks back. (Again, well within something they'll survive with)
Contact less payment are basically the same but even lower (only a few bucks are accepted without asking for a PIN)
The way actually successfulimplementations of this idea work, is that the card is yet another chip with its own identity and keys, and you can register it as an authorized id at the other companies.
i.e.: you do not *copy* 20 different credit card on it, you ask your 20 credit companies to accept also the key inside this card as ID proof.
that works nicely because wireless NFC / RFID (and contact smartcards for the LUDDITES! still using that;-) ) is standardized, meaning that in practice it really all boils down to "accept yet another key", there is no real need to modify hardware.
---
(And yes my second example is a plain watch which also has an RFID chip. Not a smartwatch with software controlled NFC. It completely predates the Apple Watch craze by a few years. And actually works with way much more different ski resorts accross europe than advertised).
When the industry decides that internal combustion engine are a too old and too problematic type of design, all the industry will start developing electric engines. All the industry, except Canonical who will start developing a nuclear fusion propelled Ubuntu Unity Car (despite the rest of the industry warning that such an endeavor might not be realist, and it would be better to stick with the same electrical drive as anyone else). After 10 years of unsuccessful development Canonical finally announces switching to electrical drive like everyone else.
Ubuntu Car come with a weird selection of colors, like shit-brown.
Despite RedHat Car being officially recommended by most garage constructor, and Microsoft Car being through the most frequent car for comuting to work, actually the most frequently Car found inside Amazon's giant car parking building will be Ubuntu Cars.
Whenever you have a problem with your car, when you start searching online, you'll find tutorials on Carexchange about fixing Ubuntu Car, and you'll have to make do with it even if you have Suse Car or a Red Hat car.
When the Moped market becomes popular and Google and Apple also start building mopeds, Canonical will announce starting to make Ubuntu Transformer Vehicle that can seamlessly be converted between car and moped forms, depending on the driver needs. Saddly there are no road specially designed for Ubuntu Mopeds. (The roads are mostly designed for Apple or Google, and are all toll roads). Surpringly, nobody buys Microsoft Moped neither, for the exact same reason, but Microsoft still keeps producing them for no clear reason. (Maybe to justify the costs of building their Moped factory out of a factory they bought from Nokia. After kicking all of the engineers out).
Microsoft will spend years trying to reverse engineer Google Mopeds to try to get their moped to drive on Google toll-roads. After ten years, Microsoft doesn't manage to produce any such moped, but surprisingly their factory starts to produce Ubuntu Cars, and is very well acclaimed for that.
Most of european continent is doing it like this : CH is another example.
So that admission is based on ability
That's the only slightly controversial subject. - In some countries you need to take a special admission exam, meaning that (richer) students that can afford to spend some time and money on preparatory class are at an advantage compared to (poorer) students that can only afford to directly go to the exam right after school. (Though there it's not a separate test, but a special test at the end of high-school, France is a well-known offender. Parts of CH have also switched to such a system) - Also some of these admission test are completely asinine and relevant to the studies (Swiss admission tests for medicine in the few uni that introduced them looks more like an IQ test than an actual test of knowledge and ability that will be useful for study).
(unless you were willing to camp out in the photocopy room at the library for a day... not that we ever did such things).
Fun fact: here (CH) the license that the university library has for books and journal actually includes a right for duplication (so student can copy a couple of page if that's all what is needed instead of buying the whole book / journal issue), and makes sure to provide enough exemplars of the book (for critical books required by lectures) that aren't allowed to be loaned (so there's always at least a few books free in the morning when you arrive).
In the 2000s part of my side-job of helping staff even consisted of preparing PDF scans of the small parts of books / journal, so students could quickly print them out, instead of having the chase down every needed small excerpt out of 20 different books / journals.
But yeah, on our side of the pond we haven't designed universities from the ground up as student dept generators.
apple and android are the same shit. what we need is open source smartphones
Android ITSELF *IS* open-source. The things which are not open-source are : - the drivers for hardware (so you're limited to whatever linux kernel the chipset vendor supplied to the handset manufacturer) - the fuckton of pre-installed bloatware by the constructor - the "Google Playstoe Service" if the handset went for an official commercial Google certification (or whatever else services and ecosystem replaces it if the constructor decided to go its own way. Such Amazon's service) - the whole booting process isn't open-source friendly, usually due to firmware signing (tivo-isation) preventing you the end-users to exerce the freedoms that GPL is supposed to grant you.
But the core of android, which gives you things such as LineagoOS (formely CyanogenMod) and Replicant (basically a free/libre only android distribution).
So android isn't the (main) problem. The problem is constructors who wants to lock the smartphone down, partly out of obligation (except for TI platforms, on most other platforms such as Qualcomm the modem and main CPU aren't as well separated - in some the modem is even the northbridge of the phone. And legally, that part is controlled by the wireless service provider holding the license for the band, not by the user), partly out of greed (bloatware !).
like the ubuntu phone was supposed to be.
Part of the problem that killed Ubuntu Phone is the same that Windows 10 Phone is still having : no app ecosystem. Android and iOS ecosystems have basically won the game. No Random Joe Sixpack User is going to use a smartphone OS that doesn't have tons of apps. And no developper is ever going to develop yet another version for a OS that doesn't have any significant amount of users, they'll only focus on the 2 big vendors. Canonical threw the towel before managing to tackle the problem. And Microsoft never managed to find a way to tap into these ecosystems (well luckily for us, that failed attempt brought us at least WSL, so it's not a loss for everyone). (Palm/HP webOS had a different problem : they bet on the wrong horse. They worked to keep compatibility with the legacy PalmOS ecosystem, but by the time the smartphone hit the market, that martket was dwindling against iOS. By the time they licensed Android app support it was to late in the lifecycle)
Luckily there *are* other alternatives now. Mer is ensemble of core component to build GNU/Linux smartphone suites (it's the descendant of Maemo/Meego). Sailfish OS by Jolla is a smartphone OS building on Mer (it's a cousin of Samsung's Tizen, etc.) Sailfish OS is already nearly entirely licensed under an opensource license. The components which aren't yet are parts of the user interface, which are going to be officially opensourced in the future, and whose source is accessible anyway, because their are written in QML+Javascript (thus end-users can already modify it and share patches, which in practice brings nearly a good enough approximation of the liberties that the future opensource license will grant).
Official commercial release of Sailfish OS (like on Jolla's one smartphone or the few commercial contractors they've got. Like Intex, Turingphone, etc. Sony is a big brandname that will eventually join) supports a licensed copy of Myriad's AlienDalvik - so Jolla users don't get left in the cold app-wise. Community ports of Sailfish OS (Fairphone 2, etc.) support SFDroid, an opensource application achieving the same goal.
Also, Jolla are the initial developpers of libhybris (That was also used by Ubuntu Phone) enabling use of drivers designed for Android userspace on a GNU/Linux userspace. Meaning that Sailfish OS can be ported even if the chipset manufecturer only provides android device drivers to the handset manufacturer.
That currently seems to be the best alternative to Android : - full blown GNU/Linux platform - most parts are licensed as open-source, the rest is similarily editable anyway - can run apps for android (so user needing them can use sailfish OS, and app devloppers don't need to target yet another platform before sailfish is popular enough).
To better adapt this old Microsoft Car meme to Apple.
7. The oil, engine, gas and alternator warning lights would be replaced with a single "General Car Fault" warning light.
7. The oil, engine, gas and alternator warning lights would be replaced with a single "Sad Mac" smiley warning light, while a spinning beachball is animated on the infotainment screen.
10. The airbag system would say "Are you sure?" before going off and start a 60 second countdown.
10. The airbag system would need to force your install the latest upgrade from iTunes be going off. (But you'll have a selection of 10 different fart sounds that can play while it deploys).
No one is cross shopping a switch and an NES Classic Mini.
That's exactly the point :
- Currently, retro-loving geeks will buy a NES Classic (of which Nintendo only makes a few bucks through licensing and that's about it). They would never ever had thought about buying a Switch. The idea would have never crossed their mind.
- If NES Classic is shut down, retro-geeks will be left without a platform. Some of them might end up biting the bullet and buy a Switch, and then re-buy all the old classics again from the virtual shop of the Switch. (Nintendo thus makes more money by selling hardware, and re-selling again ROMs of classics). The rest of the retro geeks will probably try other 3rd party unlicensed emulators, but these Nintendo is going to try to sue anyway.
Is Titanium conventional casting production that expensive?
Making the mold itself, into which the parts are cast, is expensive. When you're building cars by the hundreds everyday, it's totally worth using cast metal for the various pieces of equipement. You have a big upfront cost making the mold, but then you have hundreds of thousands of parts to divide the cost.
When you're only building a plane per month or so, making a unique piece that is only needed once per product will be damned expensive by traditional methods : - casting will get more expensive (again, the mold it self is the most expensive part, not the parts cast into it - less parts produced means, less parts to divide production cost, means higher end cost) - hiring machinists to build it is also expensive.
Suddenly laser-sintering the part becomes attractive.
And that's what these 3D production technique excel at : custom low volume parts. - Traditionally, that means it help innovation (when experimenting with a few new parts) - But at also means it's useful for something which is produced at extremely low volume and requires highly customized parts (air planes, rockets, etc.)
The NSA once allowed the Russians to conduct industrial espionage and planted information they wanted Russia to steal. 6 months later one of Russia's main oil pipelines blew up because the PLC and SCADA information they stole actually provided a RAT that the CIA used to sabotage key pumping stations.
Do you sincerly think that this was the sole unique time a US governmental agency tried to feed software with bugs planted in for the purpose to cause mayhem ?
And you are really persuaded that the USSR never ever had the slightest idea that they are receiving bogus software and never had an army of hacker for the sole purpose to review and clean such code ? (Come on, you're speaking about the USSR - which has secret service at least as good as their western counter part, if not better. Do you *really* think that they could be bluffed so easily ? Were they still seaking to acquire red mercury until the end of the cold war ?)
(Said as the descendant of a hacker who did clean code of intentionally planted bugs, on the other side of the iron curtain. Not even Russia, but a small country. So even that small country was spending efforts to sanitized any piece of code received from the west, you can only guess what kind of efforts Russia was spending).
Plus, in the specific case of that explosion in Siberia the level of cause imputable to the CIA has been debunked. Yes, CIA was attempting to feed bogus shit to the USSR in an attempt to cause mayhem (but as said above, this *was* probably a well known fact on the other side of the iron curtain). But no, that peculiar explosion wasn't caused directly by CIA, but by the same cause that also caused other catastrophes like Tchernobyl : recklessness of the involved engineers. (Pipeline is leaking ? Hey, why should we go investigate ? Just pump up the pressure to keep the gaz flowing ! Easy fix ! Also easy cause for a massive explosion)
It is true that more live with their parents and are not married.
Maybe in the US.
A growing trend seen in Europe is millenial living flatmates in a shared apartment. So, yeah they also tend not to live up the "married living in a house with a dog by mid 20s" cliché of their parents. The only difference with the US is that they're not staying in their parent's basement (probably due to europe being more densely populated, and the parents not having basements available for that due to living in apartments)
The article did not say what the immediate response of the authorities was, did radio and TV stations promptly transmit a 'do not worry' message?
How does this work in the US ? Here around in Europe, the authorities are supposed to immediately broadcast informations about the alert on all available channels (TV, radio, web, public announcement systems, etc.) informing about the nature of the threat and the proper procedure to follow to stay sage.
(Well in theory. In practice, given the relative peacefulness of life Europe, 99.9% times you're going to hear a siren, it's just a test of the system as announced the day before in the local newspaper / newscast, and the only thing you're supposed to do is just check that you can hear them and then eventually proceed with the announced evacuation drill that your employer has planned to coincide on that day).
The device isn't failing because of manufacturing defects or ordinary wear and tear or anything predictable. It's failing because it's been deliberately attacked. If I bought a computer, and someone else shot it, I'd expect the manufacturer to not be responsible.
If you look into the details, a laptop isn't (normally) designed for the purpose of sustaining gun shots. The laptop getting shot and subsequently stopping to work isn't part of its normal operating mode. Whereas a IoT device is supposed to be constantly connected to the Internet - that waht the "I" in "IoT" means. Being connected to the internet is part of their intended normal use.
If a manufacturer sells a lot of X, and the bad guys find a security hole, the manufacturer could be on the hook for an unlimited number of X without receiving any payment, since a customer could find a series of Xs bricked.
If a customer bought X, and suddenly X stops working even if the customer always used X as instructed and did nothing wrong then the manufacturer has to replace X. Period. That's the law.
It doesn't matter if the smart LED bulb stopped functioning because of a blown capacitor, or a software defect (See the spoofable firmware update on Philips smart LED bulbs). It's a light bulb that doesn't work anymore and if that happens within 24 months (10 years actual real-world warranty provided by some manufacturer like Philips) and the customer didn't do anything wrong, the manufacturer has to replace it or repair it.
Wow. In Canada, a warranty would apply to manufacturing defects, which this clearly isn't.
It clearly is. The manufacturer used a defective conponent, even if said component(*) is software (the stupidly insecure firmware) rather than hardware (it's not a broken capacitor). From the point of view of the end user, it's all the same : the user both a IoT gizmo, use it as intended, did nothing wrong, but suddenly the gizmo stopped working without any forewarning.
in EU and other european countries, manufacturing defects are defined as problems which aren't cause by neither excessive wear and tear, nor by abnormal use.
You have a IoT (say a smart LED light bulb. e.g.: whose colour you can change with an App). You use it perfectly normally as instructed in the manual (i.e.: you screwed it into some ceiling light in your living room, and use the app to change colour) (i.e.: you're not submitting it to an abnormal amount of abuse (it's not fixed on the outside of your mud bike) and you're not using it in a unusual way (you're not kicking into it as a make-shift soccer ball) ) Suddenly this IoT stop functioning (e.g.: Philips' SmartLED bulb have a buggy cloud-based firmware update system that is easy to spoof to load any payload. It could get hacked by this bricking worm). As you didn't do anything wrong, it's clearly considered as "manufacturing defect" (and in practice that's actually the case : Philips manufactured a smart LED bulb with a broken firmware - a firmware with an asinine security flaw making it easy to abuse) and thus it must be covered by warranty as required by most European jurisdictions.
They also don't claim to prevent brute force attacks, which is what this is.
The technical detailled reason why it stopped working isn't relevant. In most european countries, the only question that matters is : - Did the device suddenly stop working ? - Was it used as excepted when this occured ?(**) - Was this not expected as the normal wear and tear of the device (when used within reasonable parameters)
If the manufacturer has to eat the bill here, that's fucked up.
If the manufacturer is stupid enough to release a device running a defective firmware (stupidly insecure), they *have* to eat the bill replacing broken devices. (device broken due to their stupid firmware. not devices broken by users who aren't capable to use the device as they should).
----
(*) In lots of jurisdiction in europe, software *is* considered as a component of a device. That why in lots of countries here around you DO NOT have software patents. Only patents for devices which happen to have a software component also described in the patents claim. (**) This is also the weird reason why some customer services can legitimely require you to un-install your Linux and re-install Windows on a laptop with a defective part. That laptop was only designed to run Windows. It was never designed to run Linux. That not a normal use. (Although it's ridiculous when the warranty claim isn't about malfunctions bout about broken physical parts).
Slashdot Mirror
Are we talking theoretically, or are we talking practically? Because practically there are many choices out there for a cheap laptop that is capable of running arbitrary code.
Cheap : yes.
But cheap isn't the only characteristic that attract people to chromebooks.
The form factor is also another reason.
And most of the "run arbitrary code, and easily install Linux on them" devices tend to be heavy clunky workstation-class laptops
(again for obious market reasons : most linux users tend to be developers, its best to concentrate effort to create pro-laptops catering to them)
Chrome books tend to be extremely light and thin.
If you're on the market of a machine which doesn't break your back, and for which you hope to get supported drivers you best bets are in order : ChromeBooks then Windows ultraportable.
Usually, forget about MacBook Air, their weird embed controller won't get driver support quickly.
And that's for ulta-thin portable.
Then there are smartphone.
There it's very hard to find device allowing end-users to install arbitrary code. Usually you'll find it only on special hobbyist-oriented platforms, which tend to be expensive and with lower hardware specs (due to smaller production runs) like OpenMoko/GoldeDelicious FreeRunner/GTA04, like Pyra handheld console, etc.
There are a few consumer-oriented platforms that can optionally allow you to run arbitrary code : the above mentionned Jolla 1 by the former sacked R&D team of Nokia, Palm / HP's Pre (and the tendency has now halted, after switching hands to LG), etc.
And in between (still a smaller production run and a bit expensive for not-stellar specs. But more consumer-oriented than hobbyist oriented) : Fairphone 2.
Both cgroups and containers can be created and manipulated from the command line. Nobody bothered to do this as a PoC before going off on a tear and creating systemd.
There were command-line demos of cgroup/namespace (video of devs launching "make -j 255" while the desktop remains responsive).
What nobody bothered, is trying to rewrite the mass amount of bash script to support it.
(Specially since nearly every distro seems to write their own script madness to handle starting/stopping jobs *).
You would either need each single distro to rewrite mass amount of in-house developed shell code in order to leverage such newer kernel functionnality.
Or, you need that a few standard component that leverage the facility for you an simplify using it.
For obvious resource-saving reasons, most people went for the 2nd option.
Systemd was one of such developed facilities, and is the one who ended up the most popular. (By redhat who developed it. But also by other distributions who picked it up very early like suse).
And as usual, Canonical went for their own "NIH-syndrom" solution (upstart), before eventually joining everyone else.
---
* : which is another advantage of systemd.
Most distribution wrote their own rc?.d scripts, usually with tons of boiler-plate code (for starting, checking status, etc.)
systemd relies on much smaller simpler static configuration files - easier to edit, also easier to share.
It's easier to maintain the the content of rc?d.
On the other hand, unlike SysVInit, where much of their processing is done by calling bash (i.e.: outside of PID 1), systemd move a little bit more functionality in there (into PID 1) in order to be able to interpret the conf files.
It is also for variable random content. Imagine a service that returns a webpage containing the product (of the multiplication) of two numbers, followed by a list of links to ten other random number pairs you could try. It would take a 1kB page to write, but infinite space to archive *all* the results
And archive.org already has a correct behaviour for that :
- it wont try to download all infinity of solution in one go (e.g.: generating giga-byte worth of data out of the 1kB Perl/PHP/NodeJS/whatever source)
- instead it will occasionally rescan the page, every few days (more or less frequently, depending on popularity of the links)
It provides a small glimpse of what a user could have seen back then on the website.
By the way, back in the 2000s, this was exactly a popular way to poison SPAM robots spiders who where scanning the web for e-mail addresses.
- Either they honour robots and not scan that or any other sources of e-mail on the site.
- Or they attempt to ignore robots.txt and follow links they aren't authorised to, and end-up siphonning giga-bytes worth bogus e-mails addresses auto-generated by small perl script, which will pollute their base of harvested addresses.
Archive.org's spider might by a tiny bit more susceptible to this kind of things.
Bot as much as a SPAM email-harvesting spider (which will try to download as much as possible, much more aggressively than archive.org), but still such a labyrinth of links might get archive lost.
So no, this will not meet your needs. And that's OK, because not every product needs to be for Slashdot readers to use directly.
But on the other hand there are users who DO need such product.
If manufacturers only produce device that cater only to the most popular users, this is going to be problematic. Because nobody will produce any product that could also fill the needs of less common users.
On the otherhand, manuacturer could produce device that could, if the user is motivated enough, be converted to the needs of more peculiar users (e.g.: how easy it is to switch on developer mode on Jolla, and older HP / Palm smartphones), you end up with a device that is both cheap and mass-produced, but also can be coerced to fullfill the needs of a few atypical users who'll otherwise be left in the dust.
But do these "separate application[s]" break if pid 1 is something other than systemd?
Depends on the applications.
Boot-loader ? NTP clients ? these aren't deeply interdependent.
You could very much use these and then run openrc if you want.
These are just handled by systemd in the sens that these are program who are now developed by people who are on the systemd *project* team.
At most systemd might leverage boot-loader in the sense that it can more easily send parameters to it for the next boot.
Though other daemon might be much more interlinked with systemd's (the daemon running at PID 1) job of starting/stopping things.
(I'm thinking about daemon managing seats, sessions, and starting/stopping hardware).
These are important as over time, the Linux kernel is starting to go way much more advanced than standard POSIX behaviour.
Linux kernel, for example, offers cgroup isolation, namespaces, etc. (the facilities which are leveraged by containers such as LXC, Docker, Andbox...) which are definitely useful (separating session in different name-spaces, jailing some daemons in containers, automatically configuring the content of a container state-lessly)
The older bash-script-based mess of code that used to predate systemd has absolutely zero ability to leverage them.
SystemD is one rather successful way to deal with those things that wasn't provided by SysVinit.
Having trouble affording holiday accommodation, than buy a bloody tent, no hotels in areas zoned residential only and huge fines for those who attempt to break those planning laws.
In other countries (e.g.: France), renting apartment is considered pretty normal whereas you deffinitely aren't free to put your tent anywhere else except is a few designated camping area (that you must pay, and make reservations in advance).
Thus AirBnB-like service are considered pretty much normal there and have been exist long before (all the way back to the minitel-era)
Which shows that lobby are the real problem.
In other country (e.g.: France) on-line systems for people renting out their appartment - all the way to small hotel-like family-operated business - have existed for ages without any problems.
As such technologies started to appear (in France : all the way back to minitels) society and legislation simply adapted to it.
And they will soon be sued out of business.
a.k.a. "OMG, a few assistive tools that simplify driving(*) aren't actually a electronic horse (or donkey) that can bring me home safely even if I sleep the whole way through ?"
How this lawsuit has any merit ? Had this been filed in Europe, the lawyers and plaintiff would had been laughed away of the court room.
OTOH, similar kind of technology has been available on car of European manufacturer for quite some time (random examples: Volvo, Mercedes), and is an absolute standard with some constructors (example: VW. You can't buy even the smallest VW Up! without at least a LIDAR for in-city use).
And I haven't read anywhere of a lawsuit filed in Europe pretending that such things are a dangerous technology.
It's just tools to help. The driver is still in charge and shouldn't shut down their brain.
(And for the record, taking an innocent bystander with you when killing yourself by sheer stupidity will disqualify you from the Darwin Award)
---
(*) BTW: exactly what the word "Auto-pilot" refers to in any other field : aviation, navigation, etc.
only in the mind of a few stupid users does it mean "an electronic donkey that brings me home while I'm passed out after the bar closes"
My Subaru has an electric parking brake (my wife wanted it). I can't figure out what's wrong with a mechanical parking brake.
For a plain simple old car, an electric parking brake only makes sense for one single element :
- pulling it up is easier because it's not you exerting the actual force on the brake, but the brake's electrical motor.
If your wife doesn't have that much hand force to the point that pulling the lever is cumbersome, an electrical brake makes it much simpler to use.
(Push the button instead of try to pull the lever)
For a modern car filled with electronics, it's an entirely different wolrd of possibility : now the car can decide to put or lift the parking brake it self, and thus the car can automatically do it when needed.
- It can automatically engage it when you lock the car, and disengage when you start driving, no button push even needed.
- the adaptive cruise control or automatic parking can correctly use the parking brake on street with steep slope.
(e.g.: the car arrives at a waiting queue in front of a red light on a upward going street. the correct procedure would be to engage the parking brake when you stand still, and disengage when starting to drive again so the cars doesn't roll back a bit while you maneuver the pedals (clutch/brake/accelerator).
When using adaptive cruise control and an electric brake, the car does everything on its own - at least the car I've driven).
TFA's being Teslas, and Elon Musk being big on autopilot assisting (the latest software does also park automatically, and has been doing adaptive cruise control for a couple of versions) - I guess in this case it's the later : enabling the car to autonomously use the parking break in corresponding maneuvers. Though, this being an electric drive, there aren't any clutch or gearbox to play with, so I doubt the maneuvres are the same)
Actually, they're one of the copy-cat companies which jumped on the idea when the originating company published their idea. That company is still alive, though struggling. The biggest setback was chips. You're supposed to pay using your chip now, swiping is reserved for the restroom. These multi-card cards don't have chips.
Some do.
The idea is that you're not trying to *copy* the data from the source card's chip to the multicard's chip.
The mutlicard's chip has it's own private credential on the chip.
What you do is you register said credential as yet another acceptable ID at the other company.
(So the company isn't accepting only info of Card A - that also got copied on card B. But the company is accepting any of the private key on the chips of either card A or card B).
I can open a shared car with my train pass, because the carsharing company accepts to recognize the train pass as also identifying me.
This concept has been popular for ages for ski passes across european ski resorts : nearly all companies accept each others wireless cards (to the point that it even ended up in wrist watches).
That's why 'plastic' could never mimic a chip card; because to mimic the behaviour and 'signing capabilities' of such a card would require knowing that secret information along with associated algorithms
Or, inversely, it could hold its own sets of secret information, and the plastc compagny would register these as an acceptable form of ID / as altenate accepted signing to the other companies.
(I.e.: when you "copy" a credit card or an access card to it, what actually goes behind the curtain, is that in the DB of the bank or some other company the plastc is added as yet another accepted form of ID for you next to whatever contactless card / RFID fob you were already using).
At lest that's how it is actually implemented in the realworld by other companies that didn't go bust like plastc.
Granted, it doesn't change anything in your scenario, but given European chip 'n pin do connect, I doubt you attack would be feasible (ignoring the fact you need a 1000 unconnected terminals, which is doing to be very hard to find).
That attack would definitely be feasible.
*BUT* the unconnected terminals would be limited to a small amount only.
So at the end of the day, the bank only loses a couple of thousands of EUR, (Well within something they can live with)
or bounces the transaction back and a thousands of shops are a few dozens bucks back. (Again, well within something they'll survive with)
Contact less payment are basically the same but even lower (only a few bucks are accepted without asking for a PIN)
The way actually successful implementations of this idea work, is that the card is yet another chip with its own identity and keys, and you can register it as an authorized id at the other companies.
i.e.: you do not *copy* 20 different credit card on it, you ask your 20 credit companies to accept also the key inside this card as ID proof.
that works nicely because wireless NFC / RFID (and contact smartcards for the LUDDITES! still using that ;-) ) is standardized, meaning that in practice it really all boils down to "accept yet another key", there is no real need to modify hardware.
---
(And yes my second example is a plain watch which also has an RFID chip. Not a smartwatch with software controlled NFC. It completely predates the Apple Watch craze by a few years. And actually works with way much more different ski resorts accross europe than advertised).
Now let's talk about the Ubuntu Car.
When the industry decides that internal combustion engine are a too old and too problematic type of design, all the industry will start developing electric engines. All the industry, except Canonical who will start developing a nuclear fusion propelled Ubuntu Unity Car (despite the rest of the industry warning that such an endeavor might not be realist, and it would be better to stick with the same electrical drive as anyone else). After 10 years of unsuccessful development Canonical finally announces switching to electrical drive like everyone else.
Ubuntu Car come with a weird selection of colors, like shit-brown.
Despite RedHat Car being officially recommended by most garage constructor, and Microsoft Car being through the most frequent car for comuting to work, actually the most frequently Car found inside Amazon's giant car parking building will be Ubuntu Cars.
Whenever you have a problem with your car, when you start searching online, you'll find tutorials on Carexchange about fixing Ubuntu Car, and you'll have to make do with it even if you have Suse Car or a Red Hat car.
When the Moped market becomes popular and Google and Apple also start building mopeds, Canonical will announce starting to make Ubuntu Transformer Vehicle that can seamlessly be converted between car and moped forms, depending on the driver needs. Saddly there are no road specially designed for Ubuntu Mopeds. (The roads are mostly designed for Apple or Google, and are all toll roads). Surpringly, nobody buys Microsoft Moped neither, for the exact same reason, but Microsoft still keeps producing them for no clear reason. (Maybe to justify the costs of building their Moped factory out of a factory they bought from Nokia. After kicking all of the engineers out).
Microsoft will spend years trying to reverse engineer Google Mopeds to try to get their moped to drive on Google toll-roads. After ten years, Microsoft doesn't manage to produce any such moped, but surprisingly their factory starts to produce Ubuntu Cars, and is very well acclaimed for that.
I think Germany does something like this.
Most of european continent is doing it like this : CH is another example.
So that admission is based on ability
That's the only slightly controversial subject.
- In some countries you need to take a special admission exam, meaning that (richer) students that can afford to spend some time and money on preparatory class are at an advantage compared to (poorer) students that can only afford to directly go to the exam right after school.
(Though there it's not a separate test, but a special test at the end of high-school, France is a well-known offender. Parts of CH have also switched to such a system)
- Also some of these admission test are completely asinine and relevant to the studies (Swiss admission tests for medicine in the few uni that introduced them looks more like an IQ test than an actual test of knowledge and ability that will be useful for study).
(unless you were willing to camp out in the photocopy room at the library for a day... not that we ever did such things).
Fun fact: here (CH) the license that the university library has for books and journal actually includes a right for duplication (so student can copy a couple of page if that's all what is needed instead of buying the whole book / journal issue), and makes sure to provide enough exemplars of the book (for critical books required by lectures) that aren't allowed to be loaned (so there's always at least a few books free in the morning when you arrive).
In the 2000s part of my side-job of helping staff even consisted of preparing PDF scans of the small parts of books / journal, so students could quickly print them out, instead of having the chase down every needed small excerpt out of 20 different books / journals.
But yeah, on our side of the pond we haven't designed universities from the ground up as student dept generators.
apple and android are the same shit. what we need is open source smartphones
Android ITSELF *IS* open-source.
The things which are not open-source are :
- the drivers for hardware (so you're limited to whatever linux kernel the chipset vendor supplied to the handset manufacturer)
- the fuckton of pre-installed bloatware by the constructor
- the "Google Playstoe Service" if the handset went for an official commercial Google certification
(or whatever else services and ecosystem replaces it if the constructor decided to go its own way. Such Amazon's service)
- the whole booting process isn't open-source friendly, usually due to firmware signing (tivo-isation) preventing you the end-users to exerce the freedoms that GPL is supposed to grant you.
But the core of android, which gives you things such as LineagoOS (formely CyanogenMod) and Replicant (basically a free/libre only android distribution).
So android isn't the (main) problem. The problem is constructors who wants to lock the smartphone down, partly out of obligation (except for TI platforms, on most other platforms such as Qualcomm the modem and main CPU aren't as well separated - in some the modem is even the northbridge of the phone. And legally, that part is controlled by the wireless service provider holding the license for the band, not by the user), partly out of greed (bloatware !).
like the ubuntu phone was supposed to be.
Part of the problem that killed Ubuntu Phone is the same that Windows 10 Phone is still having : no app ecosystem.
Android and iOS ecosystems have basically won the game.
No Random Joe Sixpack User is going to use a smartphone OS that doesn't have tons of apps.
And no developper is ever going to develop yet another version for a OS that doesn't have any significant amount of users, they'll only focus on the 2 big vendors.
Canonical threw the towel before managing to tackle the problem.
And Microsoft never managed to find a way to tap into these ecosystems (well luckily for us, that failed attempt brought us at least WSL, so it's not a loss for everyone).
(Palm/HP webOS had a different problem : they bet on the wrong horse. They worked to keep compatibility with the legacy PalmOS ecosystem, but by the time the smartphone hit the market, that martket was dwindling against iOS. By the time they licensed Android app support it was to late in the lifecycle)
Luckily there *are* other alternatives now.
Mer is ensemble of core component to build GNU/Linux smartphone suites (it's the descendant of Maemo/Meego).
Sailfish OS by Jolla is a smartphone OS building on Mer (it's a cousin of Samsung's Tizen, etc.)
Sailfish OS is already nearly entirely licensed under an opensource license. The components which aren't yet are parts of the user interface, which are going to be officially opensourced in the future, and whose source is accessible anyway, because their are written in QML+Javascript (thus end-users can already modify it and share patches, which in practice brings nearly a good enough approximation of the liberties that the future opensource license will grant).
Official commercial release of Sailfish OS (like on Jolla's one smartphone or the few commercial contractors they've got. Like Intex, Turingphone, etc. Sony is a big brandname that will eventually join) supports a licensed copy of Myriad's AlienDalvik - so Jolla users don't get left in the cold app-wise.
Community ports of Sailfish OS (Fairphone 2, etc.) support SFDroid, an opensource application achieving the same goal.
Also, Jolla are the initial developpers of libhybris (That was also used by Ubuntu Phone) enabling use of drivers designed for Android userspace on a GNU/Linux userspace. Meaning that Sailfish OS can be ported even if the chipset manufecturer only provides android device drivers to the handset manufacturer.
That currently seems to be the best alternative to Android :
- full blown GNU/Linux platform
- most parts are licensed as open-source, the rest is similarily editable anyway
- can run apps for android (so user needing them can use sailfish OS, and app devloppers don't need to target yet another platform before sailfish is popular enough).
To better adapt this old Microsoft Car meme to Apple.
7. The oil, engine, gas and alternator warning lights would be replaced with a single "General Car Fault" warning light.
7. The oil, engine, gas and alternator warning lights would be replaced with a single "Sad Mac" smiley warning light, while a spinning beachball is animated on the infotainment screen.
10. The airbag system would say "Are you sure?" before going off and start a 60 second countdown.
10. The airbag system would need to force your install the latest upgrade from iTunes be going off.
(But you'll have a selection of 10 different fart sounds that can play while it deploys).
No one is cross shopping a switch and an NES Classic Mini.
That's exactly the point :
- Currently, retro-loving geeks will buy a NES Classic (of which Nintendo only makes a few bucks through licensing and that's about it).
They would never ever had thought about buying a Switch. The idea would have never crossed their mind.
- If NES Classic is shut down, retro-geeks will be left without a platform. Some of them might end up biting the bullet and buy a Switch, and then re-buy all the old classics again from the virtual shop of the Switch. (Nintendo thus makes more money by selling hardware, and re-selling again ROMs of classics).
The rest of the retro geeks will probably try other 3rd party unlicensed emulators, but these Nintendo is going to try to sue anyway.
Is Titanium conventional casting production that expensive?
Making the mold itself, into which the parts are cast, is expensive.
When you're building cars by the hundreds everyday, it's totally worth using cast metal for the various pieces of equipement. You have a big upfront cost making the mold, but then you have hundreds of thousands of parts to divide the cost.
When you're only building a plane per month or so, making a unique piece that is only needed once per product will be damned expensive by traditional methods :
- casting will get more expensive (again, the mold it self is the most expensive part, not the parts cast into it - less parts produced means, less parts to divide production cost, means higher end cost)
- hiring machinists to build it is also expensive.
Suddenly laser-sintering the part becomes attractive.
And that's what these 3D production technique excel at : custom low volume parts.
- Traditionally, that means it help innovation (when experimenting with a few new parts)
- But at also means it's useful for something which is produced at extremely low volume and requires highly customized parts (air planes, rockets, etc.)
The NSA once allowed the Russians to conduct industrial espionage and planted information they wanted Russia to steal. 6 months later one of Russia's main oil pipelines blew up because the PLC and SCADA information they stole actually provided a RAT that the CIA used to sabotage key pumping stations.
Do you sincerly think that this was the sole unique time a US governmental agency tried to feed software with bugs planted in for the purpose to cause mayhem ?
And you are really persuaded that the USSR never ever had the slightest idea that they are receiving bogus software and never had an army of hacker for the sole purpose to review and clean such code ?
(Come on, you're speaking about the USSR - which has secret service at least as good as their western counter part, if not better. Do you *really* think that they could be bluffed so easily ? Were they still seaking to acquire red mercury until the end of the cold war ?)
(Said as the descendant of a hacker who did clean code of intentionally planted bugs, on the other side of the iron curtain. Not even Russia, but a small country. So even that small country was spending efforts to sanitized any piece of code received from the west, you can only guess what kind of efforts Russia was spending).
Plus, in the specific case of that explosion in Siberia the level of cause imputable to the CIA has been debunked.
Yes, CIA was attempting to feed bogus shit to the USSR in an attempt to cause mayhem (but as said above, this *was* probably a well known fact on the other side of the iron curtain).
But no, that peculiar explosion wasn't caused directly by CIA, but by the same cause that also caused other catastrophes like Tchernobyl : recklessness of the involved engineers.
(Pipeline is leaking ? Hey, why should we go investigate ? Just pump up the pressure to keep the gaz flowing ! Easy fix ! Also easy cause for a massive explosion)
It is true that more live with their parents and are not married.
Maybe in the US.
A growing trend seen in Europe is millenial living flatmates in a shared apartment.
So, yeah they also tend not to live up the "married living in a house with a dog by mid 20s" cliché of their parents.
The only difference with the US is that they're not staying in their parent's basement (probably due to europe being more densely populated, and the parents not having basements available for that due to living in apartments)
The article did not say what the immediate response of the authorities was, did radio and TV stations promptly transmit a 'do not worry' message?
How does this work in the US ?
Here around in Europe, the authorities are supposed to immediately broadcast informations about the alert on all available channels (TV, radio, web, public announcement systems, etc.) informing about the nature of the threat and the proper procedure to follow to stay sage.
(Well in theory. In practice, given the relative peacefulness of life Europe, 99.9% times you're going to hear a siren, it's just a test of the system as announced the day before in the local newspaper / newscast, and the only thing you're supposed to do is just check that you can hear them and then eventually proceed with the announced evacuation drill that your employer has planned to coincide on that day).
The device isn't failing because of manufacturing defects or ordinary wear and tear or anything predictable. It's failing because it's been deliberately attacked. If I bought a computer, and someone else shot it, I'd expect the manufacturer to not be responsible.
If you look into the details, a laptop isn't (normally) designed for the purpose of sustaining gun shots. The laptop getting shot and subsequently stopping to work isn't part of its normal operating mode.
Whereas a IoT device is supposed to be constantly connected to the Internet - that waht the "I" in "IoT" means. Being connected to the internet is part of their intended normal use.
If a manufacturer sells a lot of X, and the bad guys find a security hole, the manufacturer could be on the hook for an unlimited number of X without receiving any payment, since a customer could find a series of Xs bricked.
If a customer bought X, and suddenly X stops working even if the customer always used X as instructed and did nothing wrong then the manufacturer has to replace X. Period. That's the law.
It doesn't matter if the smart LED bulb stopped functioning because of a blown capacitor, or a software defect (See the spoofable firmware update on Philips smart LED bulbs).
It's a light bulb that doesn't work anymore and if that happens within 24 months (10 years actual real-world warranty provided by some manufacturer like Philips) and the customer didn't do anything wrong, the manufacturer has to replace it or repair it.
Wow. In Canada, a warranty would apply to manufacturing defects, which this clearly isn't.
It clearly is.
The manufacturer used a defective conponent, even if said component(*) is software (the stupidly insecure firmware) rather than hardware (it's not a broken capacitor). From the point of view of the end user, it's all the same : the user both a IoT gizmo, use it as intended, did nothing wrong, but suddenly the gizmo stopped working without any forewarning.
in EU and other european countries, manufacturing defects are defined as problems which aren't cause by neither excessive wear and tear, nor by abnormal use.
You have a IoT (say a smart LED light bulb. e.g.: whose colour you can change with an App).
You use it perfectly normally as instructed in the manual (i.e.: you screwed it into some ceiling light in your living room, and use the app to change colour) (i.e.: you're not submitting it to an abnormal amount of abuse (it's not fixed on the outside of your mud bike) and you're not using it in a unusual way (you're not kicking into it as a make-shift soccer ball) )
Suddenly this IoT stop functioning (e.g.: Philips' SmartLED bulb have a buggy cloud-based firmware update system that is easy to spoof to load any payload. It could get hacked by this bricking worm).
As you didn't do anything wrong, it's clearly considered as "manufacturing defect" (and in practice that's actually the case : Philips manufactured a smart LED bulb with a broken firmware - a firmware with an asinine security flaw making it easy to abuse) and thus it must be covered by warranty as required by most European jurisdictions.
They also don't claim to prevent brute force attacks, which is what this is.
The technical detailled reason why it stopped working isn't relevant.
In most european countries, the only question that matters is :
- Did the device suddenly stop working ?
- Was it used as excepted when this occured ?(**)
- Was this not expected as the normal wear and tear of the device (when used within reasonable parameters)
If the manufacturer has to eat the bill here, that's fucked up.
If the manufacturer is stupid enough to release a device running a defective firmware (stupidly insecure), they *have* to eat the bill replacing broken devices.
(device broken due to their stupid firmware. not devices broken by users who aren't capable to use the device as they should).
----
(*) In lots of jurisdiction in europe, software *is* considered as a component of a device.
That why in lots of countries here around you DO NOT have software patents. Only patents for devices which happen to have a software component also described in the patents claim.
(**) This is also the weird reason why some customer services can legitimely require you to un-install your Linux and re-install Windows on a laptop with a defective part. That laptop was only designed to run Windows. It was never designed to run Linux. That not a normal use.
(Although it's ridiculous when the warranty claim isn't about malfunctions bout about broken physical parts).