I've never understood how FF manages to fsck up printing so badly. Under Windows at least with the unified model you create a device context and then render your document either to a display or to a printer via GDI calls, depending on which sort of DC you've created. Somehow though FF manages to get totally different results depending on whether it's rendering the same document to a display context or to a print context. I don't think I've ever found another app that's that bad at producing a printed version of the same document that it's just successfully rendered on the screen.
That's the sad truth about Chrome vs. Firefox. I've been a FF user since Phoenix 0.3, and conversely really dislike Chrome, but for some things you just have to use Chrome because FF sucks so much at it. The other day I was forced to use Chrome and was amazed at how responsive it was, doing things where FF just slows to a crawl for a minute or more didn't even bother Chrome. And other things can't even compare, the first time I printed off some web pages using Chrome (it was the only browser installed on the machine I was using) I was astounded at what I got, an actual copy of the web page as rendered, not a single blank page, headers and footers only, images broken or spread onto their own page, missing text, everything squashed into a single narrow column down the centre of the page, etc etc. Ever since then I haven't even bothered trying to print with FF any more, it's so unlikely to get a printed page that resembles the on-screen rendered page that you're just wasting paper and time trying to do it with FF.
That's what I thought too, Australia and NZ have been doing this for years, while the country that forced everyone into it, Bushistan, probably won't get it sorted for another decade or two. In Australia you can clear immigration in under 5 minutes via their automated system, in the US it's typically an hour, sometimes two or three.
So somehow they're saying that there are 10 billion people in the world?
Yup. And of those 10 billion, at last four billion love, love, love Australis. And another two billion want Pocket integrated into Firefox. The only downside to the Mozilla... sorry, MI//lla://: whatever it's called now good-news tour is that one or possibly two people have complained about problems with memory leaks, but luckily that affects so few people that it's not worth addressing.
I can do even better than their five attempts. Given nothing more than a couple of hard, pipe-hittin niggas with a pair of pliers and a blowtorch, I bet I can get any phone unlocked the first time what's left of the the owner is asked to do it.
+1 on all of the above, and probably all the followups further down as well. Like 3D TV, it's something that was sold based on its gimmickyness, not because it met any actual market need.
I live in Seattle and work maintenance. I can only get dial up here. It takes me 10 hours to download a 10 MB PDF.
Dialup? Luxury! When I were a lad we had to walk ten miles to our ISP (aka. library) in the rain and snow, uphill both directions, stand in line for 26 hours a day to read the one book the library had, pay the library for the privilege of reading it, and then copy it out by hand for the next person to read. Tell that to the youth of today...
Especially when combined with trick like RAM-resident root and tmp filesystems, EXT3/EXT4 on modern high-endurance flash is fine, as far as I can tell. I've run endurance checks of our current CF cards (1 or 2 gig, extended-endurance) and they are still just fine after 10-15 years of simulated activity.
So there's an interesting experiment, what would you put into a more-survivable Pi while increasing the cost by no more than $10-20 (so you prototype with the Pi and then ship the deployment-ready version)? A partial wishlist:
* Proper power protection circuitry on DC in and USB.
* Barrel jack connector with a standard 9-15V in range, so it'll run from everything from 13.8VDC down to 12V-with-cable-losses.
* Use of the watchdog. Apparently some of the early silicon had problems with this, but even the current silicon doesn't use it AFAIK.
* Use of JFFS or similar, and use of RAM-resident filesystems where possible.
* Addition of survivability features, e.g. if no network packet has been seen for x minutes/hours, restart various d's as appropriate (one of the first things I did with the first Pi I got was write a bunch of scripts that checked network connectivity and other things and auto-restarted/reconnected/rewhatever'd if required).
* Reset button with soft-reset (shutdown + reboot) and hard-reset (whack it over the head) capability.
I'm not sure precisely why it happens. Something to do with the controller on some SD cards?
That's the usual FAQ response, "you've used a bad/cheap SD card", but it's only a contributing factor. Sure, there are people who are going to use the cheapest, crappiest eBey'd Chinese knock-off SD cards they can find, but you find the same problems with good-quality Sandisk cards bought from authorised distributors (so you know they're the real thing, not a clone). In addition where I've seen the corruption (with the quality SD cards) it's at the filesystem level, not the flash block level, so it's not the SD that's doing it.
The real problem is caused by a combination of three things, use of a non-flash-suitable filesystem, use of the flash by the OS as if it was a hard disk, and use of low-survivability software + hardware (so no watchdog, no checking of subsystems with automatic restart in case of problems, no reset capability, no power management, etc), so the only way to restore functionality if there's a problem with the Pi is to pull the power. Combine those three and you've got filesystem corruption at some point pretty much guaranteed.
Again, that's the Pi's blessing and curse, it's as easy to work with as a desktop Linux PC, but it's not actually a desktop PC. It's sort of the PHP or Visual Basic of the IoT world, it's made it accessible to a huge number of people who otherwise wouldn't have access, but you do pay a price for that.
It's all about the money, as any corporation is always about.
Thus the more accurate restatement of the headline, "Foxconn indicates it would be willing to build factory in the US in exchange for massive tax breaks and government subsidies". They know which way the wind is blowing, and how to milk it for maximum gain.
Hey, glad it was useful. In case others find it useful, here's Arglebargle XIV's guide to strapping enough stuff to your Pi to make it somewhat more workable...
* Run it off a UBEC, specifically off an automotive rather than an RC one. These take 12V in via flying leads and output 5V on micro USB, so you don't have to solder on a tiny plug yourself. The ones I've got are labelled "car power technology" and claim to produce 5V at 3A, I've never drawn that much but they'll provide 1-2A without really getting warm. They're epoxy-potted, so should be fine for use outdoors.
* To get power to them, use an IPxx-rated 12V power supply, typically sold for LED lighting or water pumps in gardens. These are cheap and easily available. The UBEC compensates for any voltage drop over long cable runs, so the Pi still gets 5V even if it's fed from only 11.5V by the time it gets to wherever the Pi is.
* Don't plug the UBEC directly into your Pi, instead get a USB OTG adapter. The OTG part doesn't matter and often isn't OTG anyway, the important thing is that the "OTG" part promises a micro USB connector. These typically take micro USB in and feed it to multiple micro and standard USB outputs. So you plug your UBEC into the input, one of the micro USB outs into the Pi, and use the other USB plugs to power the USB dongles that the Pi can't power itself.
* To do this, there's a hard option and an easy one. The hard option is to build your own Y cables with power from the OTG whatsit and data from the Pi (otherwise you end up backpowering the Pi). The easy option is to use a powered hub, you power it from the OTG whatsit and plug everything else into that. Just make sure you get a hub that doesn't backpower the Pi. The best one I've found is a toroid-shaped one where the USB devices are plugged in around the outside of the toroid. Even the largest SDR has plenty of room there, and it can draw up to 1-2A of power from the UBEC if it needs it.
* If you're running multiple Pis in close proximity, don't bother with Wifi'ing them but get an Edimax 6428 V4, and specifcally a V4, Wifi swiss army chainsaw. This can act as a Wifi bridge and is powered off micro USB, so you can also hook it up to the OTG whatsit. Then each Pi gets a wired connection rather than a flaky Wifi one. This gets around the fact that (a) many Wifi dongles sold for the Pi are compatible only in the sense that when you plug them in they won't catch fire or explode (the Raspbian drivers are broken or missing so you need to build/supply your own, and every time you upgrade the kernel your networking breaks until you disassemble the device the Pi is in and install updated drivers via the wired interface) and (b) Wifi networking on the Pi is pretty flaky anyway. With Wifi done via the bridge, you've now got wired access to the Pi, eliminating a major source of problems.
That's all I can think of for now. One of the Pi's running an SDR has just shit itself again but I'm going to leave crawling out to where it is to fix it until tomorrow.
Note that the WTF isn't the use of a 32-bit index, it's HowTF you can code a system that requires 4 billion rows in a database. Announcing they've fixed it by moving to a 64-bit row index is like announcing that you're fixed a problem with plugging a 100A device into a 10A circuit by replacing the fuse that keeps blowing with a piece of 00AWG wire current-welded across the terminals.
The LiFePO4 add-on is kinda cool, but as you say it blocks pins, and means you can no longer fit the thing into a standard Pi case. Also, a single 18650 doesn't really last that long... that's another nice feature about something run off a standard 12V, you can drop a picoUPS inline to the power with the SLA battery of your choice, or use an 12V UPS targeted for CCTV use if you want a ready-made solution.
The SD card is annoyingly slow, but it does make development easy and stress free, partly, in that you can have a production and dev SD card and simply flip the card over to convert the device, and of course with the high speed reader on my laptop, I can duplicate and back up the card quickly and easily.
I was working on a commercial product based on a Pi 3 not too long ago and... it trashed its filesystem within a few days of setting it up. Interestingly, the manufacturer had anticipated this because there was a recessed area at the bottom of the case that allowed you to pull the SD card out with tweezers for reflashing, and they didn't seem too surprised when I asked them for a copy of the image. Good on them for foreseeing this, but there's no way you can ship something like this to the non-geek general public.
Though isn't eMMC basically the same: it's like the old MMC cards (i.e. SD without any of the dumb crap that no one uses) over a circuit board traces, rather than a fixed socket?
eMMC is really bad marketing because with that name you associate it with the pre-SD MMC, where it's really more towards the SSD side than the SD/MMC side, although it's definitely a poor man's SSD. Think of it as an SSD alternative for phones and tablets, which is the most common application area. (eMMC 5.1 is the current standard, with SSD-like speeds possible. They just should've called it nanoSSD or something rather than MMC anything.
Yeah, the software is always the problem, sigh. What I'd kill for is if someone did deployment-grade Pi hardware, a standard 12V supply with 2.5mm barrel jack connector (so you don't need to hang a UBEC in front of everything using a Pi), proper protection circuitry for power and USB, eMMC instead of a plug-in SD card, a watchdog that works, a reset button so you don't need to power-cycle it when it hangs (which, combined with the lack of power management and use of SD card with ext3 practically builds filesystem corruption into your device), use of JFFS or something equivalent for the flash, built-in heatsink, and a few other things. You'd need to do a slightly custom distro (JFFS rather than ext3), but it should run all the Pi stuff straight out of the box while removing a pile of the headaches that currently come with trying to build a product around a Pi.
Sure, and it does a fine job at that. OTOH the price comparison is a bit biased, sure you can buy one for $30-35, but then you have to add an external USB powered hub hacked to not back-power the Pi, and for the 2 and earlier external WiFi, and all sorts of other stuff just to get it up to a usable/useful level. It's a classic case of pay me now or pay me later. Not to mention the fact that they need more care and feeding than a three-year-old, it's only a matter of time before they corrupt their filesystem/flash (because running ext3 on flash on a system with no power conditioning is probably about the worst way you could do it) or shit themselves in some other way, so it's an endless maintenance hassle keeping them running.
(Also, if you're paying $60 for the Odroid you're being overcharged, they're $40 direct from the source. In any case I'm not saying they're the perfect solution, just an indication that you can do things a lot better at comparable cose).
The Pi is two things, Pi the hardware and Pi the infrastructure. Hardware-wise, there's a bazillion devices that "compete" with the Pi, many of them much, much better. In terms of the infrastructure, there's nothing that comes close. Until something can replicate and then supplant the entire industry that's evolved around the Pi, you can't call anything "competition". The hardware is mediocre, the infrastructure is unbeatable.
Before I get lots of flames for the hardware comment, it really is. I kinda hate saying this because it's completely changed the industry and totally fulfilled its promise as an educational toy, but dear Ghod you don't want to build a product around it. Compare it to my current go-to alternative, the Odroid C2: It has power conditioning and protection circuitry on both DC in and USB ports, it has a high-current, standard barrel jack connector for power not micro USB (so it can actually power its own USB peripherals rather than needing a hacked-up external USB powered hub or having things fail to work mysteriously), it has a massive heatsink to deal with heat issues, it has proper GigE not pretend USB ethernet (and a 64-bit CPU with 2GB RAM to drive it), it has proper eMMC storage rather than an SD card, and so on and so on, it's actually been designed by competent hardware engineers who know how to build a solid, reliable system.
It's not "Countless". Wind turbines kill between 214,000 and 368,000 birds annually - a small fraction compared with the estimated 6.8 million fatalities from collisions with cell and radio towers and the 1.4 billion to 3.7 billion deaths from cats. So if it's really migratory birds you're so worried about, you'd better ditch your cellphone. And/or kill your cat.
THat FIgur Iz a lIE! FRom tHE CeLLPhonE CompANieS. SiGNed: thE CaTT!!!!
Holy shit, MD5 and 512-bit keys, Oracle are literally twenty years behind the times in crypto. It's no wonder that a company that cares this little about security is having to push out patches that fix 270 vulnerabilities at once.
Slashdot Mirror
I've never understood how FF manages to fsck up printing so badly. Under Windows at least with the unified model you create a device context and then render your document either to a display or to a printer via GDI calls, depending on which sort of DC you've created. Somehow though FF manages to get totally different results depending on whether it's rendering the same document to a display context or to a print context. I don't think I've ever found another app that's that bad at producing a printed version of the same document that it's just successfully rendered on the screen.
That's the sad truth about Chrome vs. Firefox. I've been a FF user since Phoenix 0.3, and conversely really dislike Chrome, but for some things you just have to use Chrome because FF sucks so much at it. The other day I was forced to use Chrome and was amazed at how responsive it was, doing things where FF just slows to a crawl for a minute or more didn't even bother Chrome. And other things can't even compare, the first time I printed off some web pages using Chrome (it was the only browser installed on the machine I was using) I was astounded at what I got, an actual copy of the web page as rendered, not a single blank page, headers and footers only, images broken or spread onto their own page, missing text, everything squashed into a single narrow column down the centre of the page, etc etc. Ever since then I haven't even bothered trying to print with FF any more, it's so unlikely to get a printed page that resembles the on-screen rendered page that you're just wasting paper and time trying to do it with FF.
That's what I thought too, Australia and NZ have been doing this for years, while the country that forced everyone into it, Bushistan, probably won't get it sorted for another decade or two. In Australia you can clear immigration in under 5 minutes via their automated system, in the US it's typically an hour, sometimes two or three.
So somehow they're saying that there are 10 billion people in the world?
Yup. And of those 10 billion, at last four billion love, love, love Australis. And another two billion want Pocket integrated into Firefox. The only downside to the Mozilla... sorry, MI//lla://: whatever it's called now good-news tour is that one or possibly two people have complained about problems with memory leaks, but luckily that affects so few people that it's not worth addressing.
I can do even better than their five attempts. Given nothing more than a couple of hard, pipe-hittin niggas with a pair of pliers and a blowtorch, I bet I can get any phone unlocked the first time what's left of the the owner is asked to do it.
+1 on all of the above, and probably all the followups further down as well. Like 3D TV, it's something that was sold based on its gimmickyness, not because it met any actual market need.
I live in Seattle and work maintenance. I can only get dial up here. It takes me 10 hours to download a 10 MB PDF.
Dialup? Luxury! When I were a lad we had to walk ten miles to our ISP (aka. library) in the rain and snow, uphill both directions, stand in line for 26 hours a day to read the one book the library had, pay the library for the privilege of reading it, and then copy it out by hand for the next person to read. Tell that to the youth of today...
Especially when combined with trick like RAM-resident root and tmp filesystems, EXT3/EXT4 on modern high-endurance flash is fine, as far as I can tell. I've run endurance checks of our current CF cards (1 or 2 gig, extended-endurance) and they are still just fine after 10-15 years of simulated activity.
So there's an interesting experiment, what would you put into a more-survivable Pi while increasing the cost by no more than $10-20 (so you prototype with the Pi and then ship the deployment-ready version)? A partial wishlist:
* Proper power protection circuitry on DC in and USB.
* Barrel jack connector with a standard 9-15V in range, so it'll run from everything from 13.8VDC down to 12V-with-cable-losses.
* Use of the watchdog. Apparently some of the early silicon had problems with this, but even the current silicon doesn't use it AFAIK.
* Use of JFFS or similar, and use of RAM-resident filesystems where possible.
* Addition of survivability features, e.g. if no network packet has been seen for x minutes/hours, restart various d's as appropriate (one of the first things I did with the first Pi I got was write a bunch of scripts that checked network connectivity and other things and auto-restarted/reconnected/rewhatever'd if required).
* Reset button with soft-reset (shutdown + reboot) and hard-reset (whack it over the head) capability.
I'm sure there's plenty more...
I'm not sure precisely why it happens. Something to do with the controller on some SD cards?
That's the usual FAQ response, "you've used a bad/cheap SD card", but it's only a contributing factor. Sure, there are people who are going to use the cheapest, crappiest eBey'd Chinese knock-off SD cards they can find, but you find the same problems with good-quality Sandisk cards bought from authorised distributors (so you know they're the real thing, not a clone). In addition where I've seen the corruption (with the quality SD cards) it's at the filesystem level, not the flash block level, so it's not the SD that's doing it.
The real problem is caused by a combination of three things, use of a non-flash-suitable filesystem, use of the flash by the OS as if it was a hard disk, and use of low-survivability software + hardware (so no watchdog, no checking of subsystems with automatic restart in case of problems, no reset capability, no power management, etc), so the only way to restore functionality if there's a problem with the Pi is to pull the power. Combine those three and you've got filesystem corruption at some point pretty much guaranteed.
Again, that's the Pi's blessing and curse, it's as easy to work with as a desktop Linux PC, but it's not actually a desktop PC. It's sort of the PHP or Visual Basic of the IoT world, it's made it accessible to a huge number of people who otherwise wouldn't have access, but you do pay a price for that.
It's all about the money, as any corporation is always about.
Thus the more accurate restatement of the headline, "Foxconn indicates it would be willing to build factory in the US in exchange for massive tax breaks and government subsidies". They know which way the wind is blowing, and how to milk it for maximum gain.
Hey, glad it was useful. In case others find it useful, here's Arglebargle XIV's guide to strapping enough stuff to your Pi to make it somewhat more workable...
* Run it off a UBEC, specifically off an automotive rather than an RC one. These take 12V in via flying leads and output 5V on micro USB, so you don't have to solder on a tiny plug yourself. The ones I've got are labelled "car power technology" and claim to produce 5V at 3A, I've never drawn that much but they'll provide 1-2A without really getting warm. They're epoxy-potted, so should be fine for use outdoors.
* To get power to them, use an IPxx-rated 12V power supply, typically sold for LED lighting or water pumps in gardens. These are cheap and easily available. The UBEC compensates for any voltage drop over long cable runs, so the Pi still gets 5V even if it's fed from only 11.5V by the time it gets to wherever the Pi is.
* Don't plug the UBEC directly into your Pi, instead get a USB OTG adapter. The OTG part doesn't matter and often isn't OTG anyway, the important thing is that the "OTG" part promises a micro USB connector. These typically take micro USB in and feed it to multiple micro and standard USB outputs. So you plug your UBEC into the input, one of the micro USB outs into the Pi, and use the other USB plugs to power the USB dongles that the Pi can't power itself.
* To do this, there's a hard option and an easy one. The hard option is to build your own Y cables with power from the OTG whatsit and data from the Pi (otherwise you end up backpowering the Pi). The easy option is to use a powered hub, you power it from the OTG whatsit and plug everything else into that. Just make sure you get a hub that doesn't backpower the Pi. The best one I've found is a toroid-shaped one where the USB devices are plugged in around the outside of the toroid. Even the largest SDR has plenty of room there, and it can draw up to 1-2A of power from the UBEC if it needs it.
* If you're running multiple Pis in close proximity, don't bother with Wifi'ing them but get an Edimax 6428 V4, and specifcally a V4, Wifi swiss army chainsaw. This can act as a Wifi bridge and is powered off micro USB, so you can also hook it up to the OTG whatsit. Then each Pi gets a wired connection rather than a flaky Wifi one. This gets around the fact that (a) many Wifi dongles sold for the Pi are compatible only in the sense that when you plug them in they won't catch fire or explode (the Raspbian drivers are broken or missing so you need to build/supply your own, and every time you upgrade the kernel your networking breaks until you disassemble the device the Pi is in and install updated drivers via the wired interface) and (b) Wifi networking on the Pi is pretty flaky anyway. With Wifi done via the bridge, you've now got wired access to the Pi, eliminating a major source of problems.
That's all I can think of for now. One of the Pi's running an SDR has just shit itself again but I'm going to leave crawling out to where it is to fix it until tomorrow.
Note that the WTF isn't the use of a 32-bit index, it's HowTF you can code a system that requires 4 billion rows in a database. Announcing they've fixed it by moving to a 64-bit row index is like announcing that you're fixed a problem with plugging a 100A device into a 10A circuit by replacing the fuse that keeps blowing with a piece of 00AWG wire current-welded across the terminals.
The LiFePO4 add-on is kinda cool, but as you say it blocks pins, and means you can no longer fit the thing into a standard Pi case. Also, a single 18650 doesn't really last that long... that's another nice feature about something run off a standard 12V, you can drop a picoUPS inline to the power with the SLA battery of your choice, or use an 12V UPS targeted for CCTV use if you want a ready-made solution.
The SD card is annoyingly slow, but it does make development easy and stress free, partly, in that you can have a production and dev SD card and simply flip the card over to convert the device, and of course with the high speed reader on my laptop, I can duplicate and back up the card quickly and easily.
I was working on a commercial product based on a Pi 3 not too long ago and... it trashed its filesystem within a few days of setting it up. Interestingly, the manufacturer had anticipated this because there was a recessed area at the bottom of the case that allowed you to pull the SD card out with tweezers for reflashing, and they didn't seem too surprised when I asked them for a copy of the image. Good on them for foreseeing this, but there's no way you can ship something like this to the non-geek general public.
Though isn't eMMC basically the same: it's like the old MMC cards (i.e. SD without any of the dumb crap that no one uses) over a circuit board traces, rather than a fixed socket?
eMMC is really bad marketing because with that name you associate it with the pre-SD MMC, where it's really more towards the SSD side than the SD/MMC side, although it's definitely a poor man's SSD. Think of it as an SSD alternative for phones and tablets, which is the most common application area. (eMMC 5.1 is the current standard, with SSD-like speeds possible. They just should've called it nanoSSD or something rather than MMC anything.
If he is such a "computer security expert", why did he not have his laptop fully encrypted as well as (naturally) an OS login password?
And that would have prevented it from getting stolen how?
Yeah, the software is always the problem, sigh. What I'd kill for is if someone did deployment-grade Pi hardware, a standard 12V supply with 2.5mm barrel jack connector (so you don't need to hang a UBEC in front of everything using a Pi), proper protection circuitry for power and USB, eMMC instead of a plug-in SD card, a watchdog that works, a reset button so you don't need to power-cycle it when it hangs (which, combined with the lack of power management and use of SD card with ext3 practically builds filesystem corruption into your device), use of JFFS or something equivalent for the flash, built-in heatsink, and a few other things. You'd need to do a slightly custom distro (JFFS rather than ext3), but it should run all the Pi stuff straight out of the box while removing a pile of the headaches that currently come with trying to build a product around a Pi.
Sure, and it does a fine job at that. OTOH the price comparison is a bit biased, sure you can buy one for $30-35, but then you have to add an external USB powered hub hacked to not back-power the Pi, and for the 2 and earlier external WiFi, and all sorts of other stuff just to get it up to a usable/useful level. It's a classic case of pay me now or pay me later. Not to mention the fact that they need more care and feeding than a three-year-old, it's only a matter of time before they corrupt their filesystem/flash (because running ext3 on flash on a system with no power conditioning is probably about the worst way you could do it) or shit themselves in some other way, so it's an endless maintenance hassle keeping them running.
(Also, if you're paying $60 for the Odroid you're being overcharged, they're $40 direct from the source. In any case I'm not saying they're the perfect solution, just an indication that you can do things a lot better at comparable cose).
The Pi is two things, Pi the hardware and Pi the infrastructure. Hardware-wise, there's a bazillion devices that "compete" with the Pi, many of them much, much better. In terms of the infrastructure, there's nothing that comes close. Until something can replicate and then supplant the entire industry that's evolved around the Pi, you can't call anything "competition". The hardware is mediocre, the infrastructure is unbeatable.
Before I get lots of flames for the hardware comment, it really is. I kinda hate saying this because it's completely changed the industry and totally fulfilled its promise as an educational toy, but dear Ghod you don't want to build a product around it. Compare it to my current go-to alternative, the Odroid C2: It has power conditioning and protection circuitry on both DC in and USB ports, it has a high-current, standard barrel jack connector for power not micro USB (so it can actually power its own USB peripherals rather than needing a hacked-up external USB powered hub or having things fail to work mysteriously), it has a massive heatsink to deal with heat issues, it has proper GigE not pretend USB ethernet (and a 64-bit CPU with 2GB RAM to drive it), it has proper eMMC storage rather than an SD card, and so on and so on, it's actually been designed by competent hardware engineers who know how to build a solid, reliable system.
Oh, and it costs all of $5 more than a Pi.
It's not "Countless". Wind turbines kill between 214,000 and 368,000 birds annually - a small fraction compared with the estimated 6.8 million fatalities from collisions with cell and radio towers and the 1.4 billion to 3.7 billion deaths from cats. So if it's really migratory birds you're so worried about, you'd better ditch your cellphone. And/or kill your cat.
THat FIgur Iz a lIE! FRom tHE CeLLPhonE CompANieS. SiGNed: thE CaTT!!!!
Holy shit, MD5 and 512-bit keys, Oracle are literally twenty years behind the times in crypto. It's no wonder that a company that cares this little about security is having to push out patches that fix 270 vulnerabilities at once.
These failures would never have happened with an H5 chronometer. Maybe they should launch with one of those as an additional backup.
4.1.what? 4.1.4 was the one.
True. It pains me to say this, but when the USG says "bend over", the Australian government's response will be "how far?".
If it was a stunt, then it was a stunt on the order of "Hey, watch me ride my BMX over that jump and into the open cesspool"
If you want to do something like that, you at least need to shout "Y'all watch this!" before you do it.