Thanks to Alibaba we now know how many decades we have been ripped off here in the west. They are selling pallets of shirts at $3 per unit and we have to buy them at the store for $60+. No longer.
You know, there exist such a thing as a T-Shirt that won't get completely destroyed the first time you put it into a washing machine, and that won't be torn beyond any recognition by the 5 time you wear it. Actual good quality clothes that can stand a bit of abuse and still be useful. They tend to cost a tiny bit more that 3$ (and aren't necessarily produced in China).
But then, *those* are going to be charged $120+ at the store, so your point still stands.
possible way would be : - use a legacy proprietary cd-rom controller (some extra function in 8bits/16bits audio cards, mostly SB clones) and hookup a proprietary cd-rom. - use some isa/ata bus interface card (mostly 16bits cards, there are some 8bits cards) and hookup a standard pata optical drive
- on the legacy machine, use some isa/ata bus interface card with a boot rom (enhanced bios) and hookup a compact flash card - it will show up as a diskdrive. on the internet connected machine simply use a usb adapter and the card will show up as a usb fob.
- use some isa network card, and directly copy without needing to play with floppies (or directly downlaod it using some dos browser like arachne).
(and of course there are things like usb isa cards, and flash-to-floppy weird readers, but i never tested those)
I think a true successor of DOS would enable similar extent of tinkering in today's world. Raspberry Pi is cool for playing with GPIO pins. But writing a kernel module is a major undertaking
As you said, Raspberry PI are still full blown UNIX computer that also have GPIO pins. Meaning that you have to write complex drivers to get serious things done. Arduino is the kind of things you're look for. No kernel. Just simple code running on a micro-controller and playing with digital/analog IO.
There it's the opposite, it's when you want complex tasks that are normally cared by a kernel (networking, filesystems) that you need extra code (or use available libraries).
The effort is laudable and it is even cool from an ultra-nerd standpoint but UNIX is/was always cooler. I still do most of my best work from a UNIX shell prompt. I don't see why it is even practical to keep DOS alive
It's all nice until the day you need to upgrade one of the firmware of your linux box. And then realise that the manufacturer of your motherboard, disk/network controller, etc. only provides flash software that runs under windows. (an there's no linux flash software compatible with the hardware you want to upgrade).
So you'll have to download a bootdisk to do the flash. And gues what most of the manufacturer use to make their flash boot disk ? Yup, it's FreeDOS.
(NOTE: recently some manufacturer, in addition of the boot disk for Legacy-BIOS mode, started to provide flash software that runs as an.EFI executable under the UEFI Shell. But as long as Legacy-BIOS bootdisk are provided, you can bet most of them will be powered by FreeDOS)
Although, Glide under DOS is a thing, for a short list of games that run on Voodoo1, Voodoo Rush, Voodoo2. http://www.vogons.org/viewtopi...
The funniest part is that under Linux, the opensource Mesa3D driver used Glide as a back-end to accelerate OpenGL. (this was ported to windows once 3DFx went belly up, in order to have an up-to-date OpenGL support with the latest features - you could get an (ugly) Doom 3 running on Voodoo5).
And so some people decided to port Mesa3D together with its Glide back-end to DOS (using CWSDPMI dos extended and DJGPP compiler suite) So you can get OpenGL in MS-DOS (well, as long as you can get the sources and recompile them in DJGPP)
And of course somebody did port Quake 2 with 3Dfx acceleration on DOS.
Virtually anything that isn't a.EFI executable that can be executed from UEFI's shell, comes as a bootable floppy disk powered by FreeDOS. (and some company provide both : a UEFI-style floppy with a.EFI executable, and a Legacy BIOS-style floppy with a FreeDOS booter).
Some of us keep a small bootable FreeDOS partition around, just to have a handy environment to run firmware updates.
(Though this usage pattern is slowly getting replaced by UEFI Shell and the GPT EFI System Partition)
Except that calling, say iOS sales 'generated overseas' when the software was written in the US, using US infrastructure, etc
I don't know which would be the most appropriate answer in this thread :
- "I didn't know that New Delhi has been accepted as the 51st state"
- "And China should ask all the taxes of Cuppertino, and Apple Ireland, on the grounds that the hardware is build in China, using China infrastructues, etc."
I don't understand why none of this stuff operates locally. It's always some remote server in the cloud. I remember having IBM ViaVoice (back then I think it was called "Voice Type Dictation" or "SimplySpeaking") on my goddam Pentium 75mhz computer. After about an hour of training, it would nail mostly everything I said. I find it incredibly difficult to believe that we don't have the hardware resources necessary to perform local speech-to-text and text processing inside your house without ever touching the internet.
The problems are scaling it up and the finer small details.
Regarding speech:
Modern offline text-to-speech technology is able to handle about 95% accuracy. (Being able to feed back based on past context to tell which homophone makes more sense, etc.) - Which is damn cool already (it's only 1 in 20 words that need to be fixed ! Fucking impressive !!!) - And is pretty useful to dictate toughs for those people who speak faster than they type (i.e.: most random joe six-pack outside/. and especially outside of steno communities), they can mostly speak what they want and only fix here and there (only a single word every 20. Or about a word every 2-3 sentences). - But that's completely useless on the scale of things which are required for Siri- / Alexa- / Cortana- / Whatever- type of constant speech flux of commands. The point is to completely do away with keyboard and mouse. Not to have to pull out a keyboard (or pull out your smartphone out of your pocket) to correct every third sentence you speak to your home assistant.
The only practical application would be speaking in robotic rigid sentences. "Military-type radio speak" rigidity (Strict word ordering: "[name], [order: [verb] [noun] ]". Fixed protocols : AI should ack what it understood and ask for confirmation "[user], you ask me to [verb] the [noun] ?", and user should confirm/correct "Yes do it [=fixed sentence] / No [=fixed sentence], [followed by new order]") That is the kind of speech protocol that leaves very few ambiguity and risks of error (that's why it's used by military, law enforcement, catastrophe responders, or simply people working outdoor with very noisy radio conditions - ski teacher of a club spread accross mountains in my personnal experience). That could work nearly flawlessly with modern tech. But it is very far from the "having a casual discussion with your assistant" experience that most companies are wanting to sell.
To reach that level of fluent conversation, current experience shows (100% fully autonomous real-time text subtitling, 100% fully autonomous real-time translation, etc.) that you needs several orders magnitude more accuracy (think 99.9% accuracy. Only one missed word every thousand. Or in practice an error every day or so). And due to the law of diminishing returns, that means fuck-tons more of processing power. Several data-centers worth of processing in your basement. (Don't believe me ? Look at youtube auto-generated subtitles. And Google certainly throws more processing power at them than simply a desktop computer).
And all the above is only about *parsing* the speech (i.e.: getting the speech-to-text accurate enough). Then you need to make *sense* out of the speech.
Again, with modern technology, making the system react to a bunch of preset command is trivial (the kind where you write a plug-in to get new commands supported) and could probably be handled on raspberry pi. But again the things that these companies are trying to sell to random users are much more complex : "Having a natural conversation with your assistant".
That require three things: - tons more of processing (good bye, raspberry pi) - tons more of reference data (much more than a few commands that the user has custom pre-configured) - fuck ton of data gathering... (recording every command spoken by every user) -...coupled with analysis of reject / mis-interpreted command... (most probably by huma
Please read TFSummary until the expression : "return customer".
They don't care about your health.
They DO care a tiny bit about the customers' health. Not as much as to earn a Nobel price, but just barely enough to make sure that customer lives long enough to return again and spend their money again. (That's why they don't outright actively try to poison their customers)
One example of this is the Second Amendment. Congress commissioned a study on whether the framers intended it to protect an individual right of members of the civilian population to arm themselves as they see fit. The study went deep and came to a resounding conclusion that this was exactly the point. This was reported in 1982.
Then Congress and the executive branch completely ignored the study and continued legislating and enforcing ever more gun restrictions - to this day, nearly 35 years later. Most of the federal level legal changes that favor those who want to buy guns and use them for self defence have come from the Supreme Court, which came to the same conclusion by their own procedures.
Well, it's kind of telling when you live in a country where "constantly carrying lethal force, and being ready to use it to kill any random schmuck" seems a normal rational decision.
To us on in more peaceful countries, you sound like someone asking to introduce a new amendment in your constitution to make it legal for everyone to drive a tank around just to be able to defend themselves against any potential threat - like an invader or a terrorist ramming the crowd with a truck.
And don't start about "being able to oppose a government going rogue". They are much better solution to this problem, starting from limiting the deciding power of your Government : There's this thing called a *direct* democracy, maybe you should try it. (Or maybe you should actually start writing congress to give you the right to drive a tank around to be able to oppose a government going rogue", and you next step should be yet another amendment for a "people's right to bear nukes")
- all of the strings are going to be at least longer than the integer type you're using (there is no 3-chars long string, when you cast them to uint32 for this hack) and/or you use proper padding everywhere.
- the integer type you're using is long enough for the different string to be easily distinguishable by this point (i.e.: you're not having all of your string beginning with "keep..." when you're restricted to uint32)
(and note that both previous point are more or less going in opposite direction but, well, that happens when using pesky things like "human readable language" and other such extremely verbose input data)
- you don't mind garbage aliasing with valid string (both "disable" and "disaJGrmHbnl" resolve to the same uint32)
- or simply use this hack to sort the string in various bins and then subsequently process more (using a second cast-as-a-number switch for the next chars, or using more standard string comparison). (e.g.: the case that detect all the strings beginning with "keep" will do a second switch to check keep-?WHAT?)
In short: nice hack, but is come with so many short comings that it's best left for some internal tool and never exposed to user-data-facing usage (like the internet).
Which OSS name isn't random ? (See GIMP, Konqueror, etc.)
There is a little bit of German which has transpired into the geek culture (the "Über" prefix, the construction of the imaginary word Blinkenlights and lots of other examples
Linguistic pun are somewhat present in the landscape of OSS names (See "Pidgin")
I wanted to quickly build a realistic sounding name for an Opensource alternative to Auto-pilot. Replacing one of the keyword with a synonym or a different language isn't completely unheard of. (one alternative to EDonkey is called aMule (i.e.: name of another (Hybrid) member of the Equus genus) - an alternative for online communication is called Ekiga (a name of communication between villages in Cameroune)
Out of the few language I speak fluently, some happen to have the exact same word (a Pilot is also a Pilote in French. Useless), other aren't that much frequent on/. and would be harder to get (bulgarian has a different word - but it's written in cyrillic and Bulgarian isn't that frequent among/. geeks - though an OSS software like Jitsi does have a Bulgarian name (means 'wires')), german is the example that came to my thoughts which could stand better chance to be understood by/. geeks, while still sounding different than the english "pilot")
Germany, and specially their Autobahn, has a strong connotation with cars and driving anyway (and also with engineering), and would be a realistic language that could be picked up by an opensource project IRL
For all of the above reasons, "Fahrer" was the thing that sprang into mind during the couple of seconds I decided to come up with this quick joke about a parody OSS alternative to Tesla's Autopilot. Sure, there would probably have been better ideas, but like I said, I only spent a few seconds coming up with the name. Even this explanation is way to much long for just a simple joke.
I understand where you are coming from, but I would point out that surfacing a road is not cheap. The raw materials are a small part of the cost. Closing the road, having engineers on site, equipment on site, labourers to do the work, and then confirmation that it meets the requires spec (particularly important on fast roads)...
Because on the other hand, pre-fab street pavement is going to automagically jump out of the factory and directly install it self where needed ? (...though this might actually become possible within a century of robotics development...)
Nope. Both will have costs for installation, both will require closing roads, etc.
The only difference is that, purely as a street surface material, (normal non solar) pre-fab street pavement might not that much more expensive than some of the high quality asphalt covering used accross Europe (the most durable possible to minimize needs to repair ; noise reducing properties ; etc.) and might be a little bit faster to produce and install.
So you've arrived at the logical conclusion that a plain non solar pre-fab street pavement might be not such a bad idea. So what's the next logical step ?
" - Hey, let's cram into the pre-fab tile a fragile technology that is awfully more complex, cost outrageously much more, will now require the presence of electricians just to install, and requires tons of engineering in the first place to actually get developped !" Yeah, I don't see why so many people are complaining about this idea.
In 2016, it simply doesn't make sens to even start considering putting photovoltaic cells on street pavement - for anything except just as a proof of concept at some science fair just to demo what we could be thinking to develop after a decade.
To me, it all makes as much sense as "crowd-funding to create a *fast-food chain* selling burgers out of vat-grown meat on the wonderful grounds of 'Cruelty-free, 100% guaranteed NON-murder-meat !'. Openning : Next month !". In 2016. When a single burger of cultured meat costs in the price range of million dollars.
Yes, one day, once the process is scaled to the point where it is economically viable - vat-grown bugers will definitely be the way to go (on multiple grounds. Not only on ethical ground regarding animal welfare, but also on ground that growing a culture is much less stressing the environment than growing animal which in turn are going to need cultured food, etc.)
For now, if you need that much desperately cruelty-free foods there are much more viable option if you want to open a fast-food chain next month (tofu, falafels, etc.) and leave the vat-grown burger to the scientist for what it is worth now : proof of concept of what could technologically be achievable one day.
IMHO it just seems like yet another reason to not buy a Tesla.
Oh, come on! This is Slashdot !
Fixing that for you: it just seems like yet another reason to start our own "GNU OpenAutoFahrer" !
We should register a GitHub repository like *right now*. And be ready to fork it as "LibreAutoFahrer" after 2 year due to creative dispute in the developer community.
Yes, government own the surface occupied currently by the streets. So they want to make this surface more useful.
But given the engineering complexity of trying to find a way to cram the delicate and expensive technology (PV panels) into pre-fab street pavement, from a purely economic point of view, it would make much more sense to invest the money into erecting poles (when there isn't already a handy above-ground surface like noise barriers, a roofing, etc.) and putting plain simple vanilla panels. They will also put the surface they own to use (prduce electricity) but at a fraction of the cost.
(Also by increasing thusly the demand for solar panel, they help driving their cost down. Which means that by *buying panels to put them beside the road now*, they'll help making them cheaper within a decade, to the point that it might become economically smart to try to cram them into pre-fab street pavement by 2026).
If you can spend the same or even a bit less over a few decades by installing a pre-fab road surface with solar PV, you will do it even if that PV is less efficient than it would be on a roof.
The thing is, adding photovoltaic capability to a road isn't trivial. At all. It's not just using the king of "coat of Photo Voltaic paint" that is mentioned in some Sci-Fi books that would be just mixed with the road's tar (that would be rather trivially simple, if it existed).
It's need to go at great length and expenses to achieve the engineering feat of taking something which is expensive and fragile and never designed to sustain repeated mechanical stress (a solar panel) and try to engineer around the limitation to cram it into a road tile.
To be more precise:
There are advantages to pre-fabricated surfaces mass produced in a factory and quickly laid on site. The fact that they can put solar PV in the surface is just a bonus to reduce total cost of ownership.
The problem is this thing you call "a bonus" (adding a PV panel into the pre-fab surface) is not a small feat at all. In the current state of affairs (technology available in this decade), it will require a tremendous amount of engineering, cost a tons of money, will require an enormous amount of compromises in order to pull of... The sheer amount of investment to achieve this completely dwarfs any potential reduction of cost of ownership.
All the while putting the solar panel beside the road is a viable and much cheaper solution.
This is exactly the same kind of overcomplicated and expensive over-engineering, like trying to cram an electric handle bar warmer in a bike, when you could just use fucking gloves
(But who knows, as regular PV panel become more popular, and strat to be put to lots of use, maybe by next decade, they will get much cheaper and slowly become more durable. To the point wher in 2026 it might be not stupid to try to find a way to engineer them into pre-fab pavement).
Once they start mass production the cost will fall. When considering the cost, you have to factor in labour costs and the cost of closing the road for the time required to resurface it too, and how long the road surface will last, and what the on-going maintenance costs are.
And in the meantime, putting the solar panels *beside the road* (*) is still cheaper, more energy efficient and their installation is a tiny bit less invasive to traffic.
--
(*) : like roofing over a bike path, on the roof of noise barriers, or simply along the road, etc. I.e.: places where the surface also belongs to the department of public roads, but where the panels are much more efficient by being better oriented and not shadowed by the traffic, where aren't subject to constant wear and tear by said traffic, and thus won't need tons of engineering to come up with a solution that could protect tham (like TFA's silicon layer).
You just have no idea how many things could go wrong in a such seemingly simple plan.
If even Microsoft and Sony can't manage to get crypto right to protect their game consoles, you can bet that small noname fly-by-night chinese constructors are going to completely b0rk their work.
Just of the top of my head : - fixed IP and/or address : can be spoofed, or control of the domain name could be lost. - "if a new is found download it" : nearly every single word of this sentence has a couple of embarrassingly stupid bug opportunities like buffer overflows, of by 1, etc. From the purely security point of view: a rookie garanteed to forget to check if the payload downloaded can fit into the download area (remember : at this step we haven't checked yet the legitimacy of the payload). - signature check : I won't even go in the territory of stolen private master key (hello blueray consortium !) You have realworld hardware that does asinine stuff like checking only the signature of thea update's header (free to put whatever payload you want). Or check a non cryptographic checksum.
And now for the "you definitely need a crypto guy": you need to make sure all of the above isn't leaking critical data. (the Smart LED bulb embed is likely to pull it's power from the same circuitry as the light source. If CPU activity is leaked in humanly-imperceptible blinking, that means that an attacker could steal some access token simply by watching the shimmering of light through the window from the outside using a high-speed camera. No even need for direct physical access)
And that's without taking into account even more stupiderer shit. Like the code-path ending up executing the upgrade anyway, no matter is some test failed. Because in their rush to produce the cheapest shit as fast as possible in order to hit the shelf before christmas, they didn't even properly test their codepaths.
Yup, probably you could more or less design a not to bad upgrade scheme. But you're a/.er, with probably long experience and proper education.
That's not the case of the countless over-worked, over-stressed, under-qualified slav... huh "employees" in some asian sweat-shop that must clob it together on a shoe string budget and completely unrealistic time constrains. And got pulled into that position on the ground that on last month's gizmo project at the same workshop he wrote some script (used in the driver installer), making the employee instant "computer stuff guru".
And if even a big name brand like Philips can't properly secure their Smart LED bulbs, you can only begin to imagine the Coding-Horror/Daily WTF level of atrocities which go in the small noname chinese shops where most of the cheapest shit is going to get outsourced.
So no. Making a simple auto-upgrade isn't easy without pulling people whose experties is in security/crypto.
You need to have a competent guy in the security/crypto just to check and oversee that the rest of the software team didn't botch the firmware.
And that's for every single internet-connect shit in the house. Including the damn stupid "Smart LED bulb" or "Internet connected fridge", because all of these are very likely to be on the same WiFi network as the Synology "all in one, ready to use" file server which contains all the juicy bits (important documents over CIFS/SMB) and which could be hacked (much more potential for a zombie demon running on the file server, that on the light-bulb).
Have the OS of the fridge/TV/whatever baked into the chip somehow (physically baked, or write-once EPROM or whatever).
Just as a side-note, for information: EPROM : erase-able programmable read-only memory. (and EEPROM are electrically-erasable - as opposed to other methods like UV light). (so you would need to drop the first E).
I'm probably missing something here, though.
There are 2 different problem:
TL;DR: exploitable bugs permanently burning into ROM ; lower cost of production allowing last-minute firmware changes.
I. - yes, if the firmware is in a non-re-programmable ROM, an attacker could not permanently install a backdoor on your smart-LED-lightbulb. - but if the smart-LED-lightbulb's firmware has a known vulnerability, an attacker could use it to take over the currently running linux server in RAM. The attacks won't survive a reboot (un-screwing the ligh-bulb ?) but as long as the bulb is powered and its server is running, maliciously injected code could be running. - so you would need a way to upgrade the firmware to something more secure. On a bigger gizmo such thing could be possible by swapping socketed ROM chips (that's how I received an upgrade to my eMagine 3D Visor Z800 HMD - they shipped me a small ROM chip and pincer to help swapping them). But given the tendencies of modern ultra-tiny-sized gizmos that is going to be hard (common: light bulbs. Modern LED bulbs hide nearly all their electronics inside the screw. A socketed field-replaceable ROM chip is nearly as big as all these electronics) (and that's not considering things like SD cards which contain a wireless linux file server - like PQI, Toshiba, etc. the whole gizmo is *smaller* than most socketable ROM chips).
II. - nowadays the total cost of production of a gizmo using some EEPROM or eMMC is much lower. Yup the hardware itself is probably slightly more expensive than ROM. BUT having something that is easy field upgradeable means that the firmware can be hastily written in parallel at the same time as the hardware is produced, can be fixed in last minute until it's more or less functional and then flash it on the production hardware as it leaves assembly, just before packing into its box. This makes much lower production costs. (Due to the easier dev cycles)
As opposed of needing a fully ready ROM with the firmware permanently burned into it as you start producing the hardware. (Needs to be already ready and debugged at the moment you start ramping up production. Meaning that you need several cycles of prototypes before to develop the ROM). Or trying to make a gadget that can accept both EEPROM (in the dev prototype) and can be swapped with a ROM without much further hardware re-design in the final production device.
"automatic security updates" isn't such an attracting key point to put on a box to get more consumer. But "this devices has 2x more pixels than the competition and you can control it from a smartphone app" is.
(And a corollary: A gizmo that gets updated regularily will get fixed and new feature for a longer time. This require work from the company (paying devs) This means fewer units sold to replace obsolete models)
Main reason number 2 :
Just wait until hackers find way to spoof update source, and use it as a way to install their shit on your IoT gadget (e.g.: that's a vulnerability that's been found on Philips Smart LED light bulbs).
Making auto-updates work correctly is HARD. - It require advanced knowledge in cryptography - You're at risk of TIVO-ising the gizmo if you do it wrong - This requires that the company that makes the broken gizmo that needs a firmware upgrade be still around tomorrow. That might be the case with Microsoft, but that's hardly the case with countless asian maker of cheap no-name stuff.
They bring their own snack food or hit the vending machine. Or they gorge themselves before or after work.
In addition to the junk food (snacks and industrial), there is direct effect due to the *fast eating* (insuline peak, blablabla....) disruption of daily rythm... which can also contribute to the increased chronic stress (increased corticosteroids, etc.) which also has a bad long term effect on health.
TL;DR: the junk food itself isn't the only cause of obesity, the overstress is also a major one.
Slashdot Mirror
Thanks to Alibaba we now know how many decades we have been ripped off here in the west. They are selling pallets of shirts at $3 per unit and we have to buy them at the store for $60+. No longer.
You know, there exist such a thing as a T-Shirt that won't get completely destroyed the first time you put it into a washing machine, and that won't be torn beyond any recognition by the 5 time you wear it.
Actual good quality clothes that can stand a bit of abuse and still be useful.
They tend to cost a tiny bit more that 3$ (and aren't necessarily produced in China).
But then, *those* are going to be charged $120+ at the store, so your point still stands.
possible way would be :
- use a legacy proprietary cd-rom controller (some extra function in 8bits/16bits audio cards, mostly SB clones) and hookup a proprietary cd-rom.
- use some isa/ata bus interface card (mostly 16bits cards, there are some 8bits cards) and hookup a standard pata optical drive
- on the legacy machine, use some isa/ata bus interface card with a boot rom (enhanced bios) and hookup a compact flash card - it will show up as a diskdrive.
on the internet connected machine simply use a usb adapter and the card will show up as a usb fob.
- use some isa network card, and directly copy without needing to play with floppies (or directly downlaod it using some dos browser like arachne).
(and of course there are things like usb isa cards, and flash-to-floppy weird readers, but i never tested those)
I think a true successor of DOS would enable similar extent of tinkering in today's world. Raspberry Pi is cool for playing with GPIO pins. But writing a kernel module is a major undertaking
As you said, Raspberry PI are still full blown UNIX computer that also have GPIO pins. Meaning that you have to write complex drivers to get serious things done.
Arduino is the kind of things you're look for. No kernel. Just simple code running on a micro-controller and playing with digital/analog IO.
There it's the opposite, it's when you want complex tasks that are normally cared by a kernel (networking, filesystems) that you need extra code (or use available libraries).
The effort is laudable and it is even cool from an ultra-nerd standpoint but UNIX is/was always cooler. I still do most of my best work from a UNIX shell prompt. I don't see why it is even practical to keep DOS alive
It's all nice until the day you need to upgrade one of the firmware of your linux box.
And then realise that the manufacturer of your motherboard, disk/network controller, etc. only provides flash software that runs under windows.
(an there's no linux flash software compatible with the hardware you want to upgrade).
So you'll have to download a bootdisk to do the flash.
And gues what most of the manufacturer use to make their flash boot disk ?
Yup, it's FreeDOS.
(NOTE: recently some manufacturer, in addition of the boot disk for Legacy-BIOS mode, started to provide flash software that runs as an .EFI executable under the UEFI Shell.
But as long as Legacy-BIOS bootdisk are provided, you can bet most of them will be powered by FreeDOS)
Although, Glide under DOS is a thing, for a short list of games that run on Voodoo1, Voodoo Rush, Voodoo2.
http://www.vogons.org/viewtopi...
The funniest part is that under Linux, the opensource Mesa3D driver used Glide as a back-end to accelerate OpenGL.
(this was ported to windows once 3DFx went belly up, in order to have an up-to-date OpenGL support with the latest features - you could get an (ugly) Doom 3 running on Voodoo5).
And so some people decided to port Mesa3D together with its Glide back-end to DOS (using CWSDPMI dos extended and DJGPP compiler suite)
So you can get OpenGL in MS-DOS (well, as long as you can get the sources and recompile them in DJGPP)
And of course somebody did port Quake 2 with 3Dfx acceleration on DOS.
These days, I'd guess 90% of people using FreeDOS are using it for playing DOS games
Do not underestimate all the various boot disks to upgrade firmware (BIOS, disk/network controller firmware, etc.)
Lots of them use FreeDOS to boot a floppy in Legacy-BIOS mode.
(Although this niche is progressively getting replaced/supplemented by flash tools running as .EFI executable within UEFI Shell).
Virtually anything that isn't a .EFI executable that can be executed from UEFI's shell, comes as a bootable floppy disk powered by FreeDOS. .EFI executable, and a Legacy BIOS-style floppy with a FreeDOS booter).
(and some company provide both : a UEFI-style floppy with a
Some of us keep a small bootable FreeDOS partition around, just to have a handy environment to run firmware updates.
(Though this usage pattern is slowly getting replaced by UEFI Shell and the GPT EFI System Partition)
Except that calling, say iOS sales 'generated overseas' when the software was written in the US, using US infrastructure, etc
I don't know which would be the most appropriate answer in this thread :
- "I didn't know that New Delhi has been accepted as the 51st state"
- "And China should ask all the taxes of Cuppertino, and Apple Ireland, on the grounds that the hardware is build in China, using China infrastructues, etc."
I don't understand why none of this stuff operates locally. It's always some remote server in the cloud. I remember having IBM ViaVoice (back then I think it was called "Voice Type Dictation" or "SimplySpeaking") on my goddam Pentium 75mhz computer. After about an hour of training, it would nail mostly everything I said. I find it incredibly difficult to believe that we don't have the hardware resources necessary to perform local speech-to-text and text processing inside your house without ever touching the internet.
The problems are scaling it up and the finer small details.
Regarding speech :
Modern offline text-to-speech technology is able to handle about 95% accuracy. (Being able to feed back based on past context to tell which homophone makes more sense, etc.) /. and especially outside of steno communities), they can mostly speak what they want and only fix here and there (only a single word every 20. Or about a word every 2-3 sentences).
- Which is damn cool already (it's only 1 in 20 words that need to be fixed ! Fucking impressive !!!)
- And is pretty useful to dictate toughs for those people who speak faster than they type (i.e.: most random joe six-pack outside
- But that's completely useless on the scale of things which are required for Siri- / Alexa- / Cortana- / Whatever- type of constant speech flux of commands. The point is to completely do away with keyboard and mouse. Not to have to pull out a keyboard (or pull out your smartphone out of your pocket) to correct every third sentence you speak to your home assistant.
The only practical application would be speaking in robotic rigid sentences. "Military-type radio speak" rigidity
(Strict word ordering: "[name], [order: [verb] [noun] ]". Fixed protocols : AI should ack what it understood and ask for confirmation "[user], you ask me to [verb] the [noun] ?", and user should confirm/correct "Yes do it [=fixed sentence] / No [=fixed sentence], [followed by new order]")
That is the kind of speech protocol that leaves very few ambiguity and risks of error (that's why it's used by military, law enforcement, catastrophe responders, or simply people working outdoor with very noisy radio conditions - ski teacher of a club spread accross mountains in my personnal experience).
That could work nearly flawlessly with modern tech.
But it is very far from the "having a casual discussion with your assistant" experience that most companies are wanting to sell.
To reach that level of fluent conversation, current experience shows (100% fully autonomous real-time text subtitling, 100% fully autonomous real-time translation, etc.) that you needs several orders magnitude more accuracy (think 99.9% accuracy. Only one missed word every thousand. Or in practice an error every day or so). And due to the law of diminishing returns, that means fuck-tons more of processing power. Several data-centers worth of processing in your basement.
(Don't believe me ? Look at youtube auto-generated subtitles. And Google certainly throws more processing power at them than simply a desktop computer).
And all the above is only about *parsing* the speech (i.e.: getting the speech-to-text accurate enough). Then you need to make *sense* out of the speech.
Again, with modern technology, making the system react to a bunch of preset command is trivial (the kind where you write a plug-in to get new commands supported) and could probably be handled on raspberry pi.
But again the things that these companies are trying to sell to random users are much more complex : "Having a natural conversation with your assistant".
That require three things : ...coupled with analysis of reject / mis-interpreted command... (most probably by huma
- tons more of processing (good bye, raspberry pi)
- tons more of reference data (much more than a few commands that the user has custom pre-configured)
- fuck ton of data gathering... (recording every command spoken by every user)
-
Please read TFSummary until the expression : "return customer".
They don't care about your health.
They DO care a tiny bit about the customers' health. Not as much as to earn a Nobel price, but just barely enough to make sure that customer lives long enough to return again and spend their money again.
(That's why they don't outright actively try to poison their customers)
wish I had points to mod the parent up. Not everything is an evil M$ plan.
Yup, there is sometimes an evil M$ coincidence...
One example of this is the Second Amendment. Congress commissioned a study on whether the framers intended it to protect an individual right of members of the civilian population to arm themselves as they see fit. The study went deep and came to a resounding conclusion that this was exactly the point. This was reported in 1982.
Then Congress and the executive branch completely ignored the study and continued legislating and enforcing ever more gun restrictions - to this day, nearly 35 years later. Most of the federal level legal changes that favor those who want to buy guns and use them for self defence have come from the Supreme Court, which came to the same conclusion by their own procedures.
Well, it's kind of telling when you live in a country where "constantly carrying lethal force, and being ready to use it to kill any random schmuck" seems a normal rational decision.
To us on in more peaceful countries, you sound like someone asking to introduce a new amendment in your constitution to make it legal for everyone to drive a tank around just to be able to defend themselves against any potential threat - like an invader or a terrorist ramming the crowd with a truck.
And don't start about "being able to oppose a government going rogue". They are much better solution to this problem, starting from limiting the deciding power of your Government : There's this thing called a *direct* democracy, maybe you should try it.
(Or maybe you should actually start writing congress to give you the right to drive a tank around to be able to oppose a government going rogue", and you next step should be yet another amendment for a "people's right to bear nukes")
which only works as long as :
- all of the strings are going to be at least longer than the integer type you're using
(there is no 3-chars long string, when you cast them to uint32 for this hack)
and/or you use proper padding everywhere.
- the integer type you're using is long enough for the different string to be easily distinguishable by this point
(i.e.: you're not having all of your string beginning with "keep..." when you're restricted to uint32)
(and note that both previous point are more or less going in opposite direction but, well, that happens when using pesky things like "human readable language" and other such extremely verbose input data)
- you don't mind garbage aliasing with valid string (both "disable" and "disaJGrmHbnl" resolve to the same uint32)
- or simply use this hack to sort the string in various bins and then subsequently process more (using a second cast-as-a-number switch for the next chars, or using more standard string comparison). (e.g.: the case that detect all the strings beginning with "keep" will do a second switch to check keep-?WHAT?)
In short: nice hack, but is come with so many short comings that it's best left for some internal tool and never exposed to user-data-facing usage (like the internet).
I know I shouldn't explain the joke, but....
Why name it in German? that seems really random.
Because :
For all of the above reasons, "Fahrer" was the thing that sprang into mind during the couple of seconds I decided to come up with this quick joke about a parody OSS alternative to Tesla's Autopilot. Sure, there would probably have been better ideas, but like I said, I only spent a few seconds coming up with the name.
Even this explanation is way to much long for just a simple joke.
I understand where you are coming from, but I would point out that surfacing a road is not cheap. The raw materials are a small part of the cost. Closing the road, having engineers on site, equipment on site, labourers to do the work, and then confirmation that it meets the requires spec (particularly important on fast roads)...
Because on the other hand, pre-fab street pavement is going to automagically jump out of the factory and directly install it self where needed ?
(...though this might actually become possible within a century of robotics development...)
Nope. Both will have costs for installation, both will require closing roads, etc.
The only difference is that, purely as a street surface material, (normal non solar) pre-fab street pavement might not that much more expensive than some of the high quality asphalt covering used accross Europe (the most durable possible to minimize needs to repair ; noise reducing properties ; etc.) and might be a little bit faster to produce and install.
So you've arrived at the logical conclusion that a plain non solar pre-fab street pavement might be not such a bad idea. So what's the next logical step ?
" - Hey, let's cram into the pre-fab tile a fragile technology that is awfully more complex, cost outrageously much more, will now require the presence of electricians just to install, and requires tons of engineering in the first place to actually get developped !"
Yeah, I don't see why so many people are complaining about this idea.
In 2016, it simply doesn't make sens to even start considering putting photovoltaic cells on street pavement - for anything except just as a proof of concept at some science fair just to demo what we could be thinking to develop after a decade.
To me, it all makes as much sense as "crowd-funding to create a *fast-food chain* selling burgers out of vat-grown meat on the wonderful grounds of 'Cruelty-free, 100% guaranteed NON-murder-meat !'. Openning : Next month !". In 2016. When a single burger of cultured meat costs in the price range of million dollars.
Yes, one day, once the process is scaled to the point where it is economically viable - vat-grown bugers will definitely be the way to go
(on multiple grounds. Not only on ethical ground regarding animal welfare, but also on ground that growing a culture is much less stressing the environment than growing animal which in turn are going to need cultured food, etc.)
For now, if you need that much desperately cruelty-free foods there are much more viable option if you want to open a fast-food chain next month (tofu, falafels, etc.)
and leave the vat-grown burger to the scientist for what it is worth now : proof of concept of what could technologically be achievable one day.
IMHO it just seems like yet another reason to not buy a Tesla.
Oh, come on! This is Slashdot !
Fixing that for you:
it just seems like yet another reason to start our own "GNU OpenAutoFahrer" !
We should register a GitHub repository like *right now*.
And be ready to fork it as "LibreAutoFahrer" after 2 year due to creative dispute in the developer community.
Yes, government own the surface occupied currently by the streets.
So they want to make this surface more useful.
But given the engineering complexity of trying to find a way to cram the delicate and expensive technology (PV panels) into pre-fab street pavement,
from a purely economic point of view, it would make much more sense to invest the money into erecting poles (when there isn't already a handy above-ground surface like noise barriers, a roofing, etc.) and putting plain simple vanilla panels.
They will also put the surface they own to use (prduce electricity) but at a fraction of the cost.
(Also by increasing thusly the demand for solar panel, they help driving their cost down. Which means that by *buying panels to put them beside the road now*, they'll help making them cheaper within a decade, to the point that it might become economically smart to try to cram them into pre-fab street pavement by 2026).
If you can spend the same or even a bit less over a few decades by installing a pre-fab road surface with solar PV, you will do it even if that PV is less efficient than it would be on a roof.
The thing is, adding photovoltaic capability to a road isn't trivial. At all.
It's not just using the king of "coat of Photo Voltaic paint" that is mentioned in some Sci-Fi books that would be just mixed with the road's tar
(that would be rather trivially simple, if it existed).
It's need to go at great length and expenses to achieve the engineering feat of taking something which is expensive and fragile and never designed to sustain repeated mechanical stress (a solar panel) and try to engineer around the limitation to cram it into a road tile.
To be more precise :
There are advantages to pre-fabricated surfaces mass produced in a factory and quickly laid on site. The fact that they can put solar PV in the surface is just a bonus to reduce total cost of ownership.
The problem is this thing you call "a bonus" (adding a PV panel into the pre-fab surface) is not a small feat at all.
In the current state of affairs (technology available in this decade), it will require a tremendous amount of engineering, cost a tons of money, will require an enormous amount of compromises in order to pull of...
The sheer amount of investment to achieve this completely dwarfs any potential reduction of cost of ownership.
All the while putting the solar panel beside the road is a viable and much cheaper solution.
This is exactly the same kind of overcomplicated and expensive over-engineering, like trying to cram an electric handle bar warmer in a bike, when you could just use fucking gloves
(But who knows, as regular PV panel become more popular, and strat to be put to lots of use, maybe by next decade, they will get much cheaper and slowly become more durable. To the point wher in 2026 it might be not stupid to try to find a way to engineer them into pre-fab pavement).
Once they start mass production the cost will fall. When considering the cost, you have to factor in labour costs and the cost of closing the road for the time required to resurface it too, and how long the road surface will last, and what the on-going maintenance costs are.
And in the meantime, putting the solar panels *beside the road* (*) is still cheaper, more energy efficient and their installation is a tiny bit less invasive to traffic.
--
(*) : like roofing over a bike path, on the roof of noise barriers, or simply along the road, etc. I.e.: places where the surface also belongs to the department of public roads, but where the panels are much more efficient by being better oriented and not shadowed by the traffic, where aren't subject to constant wear and tear by said traffic, and thus won't need tons of engineering to come up with a solution that could protect tham (like TFA's silicon layer).
Yup. It's a simple 3 point plan.
You just have no idea how many things could go wrong in a such seemingly simple plan.
If even Microsoft and Sony can't manage to get crypto right to protect their game consoles,
you can bet that small noname fly-by-night chinese constructors are going to completely b0rk their work.
Just of the top of my head :
- fixed IP and/or address : can be spoofed, or control of the domain name could be lost.
- "if a new is found download it" : nearly every single word of this sentence has a couple of embarrassingly stupid bug opportunities like buffer overflows, of by 1, etc.
From the purely security point of view: a rookie garanteed to forget to check if the payload downloaded can fit into the download area (remember : at this step we haven't checked yet the legitimacy of the payload).
- signature check : I won't even go in the territory of stolen private master key (hello blueray consortium !) You have realworld hardware that does asinine stuff like checking only the signature of thea update's header (free to put whatever payload you want). Or check a non cryptographic checksum.
And now for the "you definitely need a crypto guy": you need to make sure all of the above isn't leaking critical data. (the Smart LED bulb embed is likely to pull it's power from the same circuitry as the light source. If CPU activity is leaked in humanly-imperceptible blinking, that means that an attacker could steal some access token simply by watching the shimmering of light through the window from the outside using a high-speed camera. No even need for direct physical access)
And that's without taking into account even more stupiderer shit. Like the code-path ending up executing the upgrade anyway, no matter is some test failed. Because in their rush to produce the cheapest shit as fast as possible in order to hit the shelf before christmas, they didn't even properly test their codepaths.
Yup, probably you could more or less design a not to bad upgrade scheme. But you're a /.er, with probably long experience and proper education.
That's not the case of the countless over-worked, over-stressed, under-qualified slav... huh "employees" in some asian sweat-shop that must clob it together on a shoe string budget and completely unrealistic time constrains. And got pulled into that position on the ground that on last month's gizmo project at the same workshop he wrote some script (used in the driver installer), making the employee instant "computer stuff guru".
And if even a big name brand like Philips can't properly secure their Smart LED bulbs, you can only begin to imagine the Coding-Horror/Daily WTF level of atrocities which go in the small noname chinese shops where most of the cheapest shit is going to get outsourced.
So no.
Making a simple auto-upgrade isn't easy without pulling people whose experties is in security/crypto.
You need to have a competent guy in the security/crypto just to check and oversee that the rest of the software team didn't botch the firmware.
And that's for every single internet-connect shit in the house. Including the damn stupid "Smart LED bulb" or "Internet connected fridge", because all of these are very likely to be on the same WiFi network as the Synology "all in one, ready to use" file server which contains all the juicy bits (important documents over CIFS/SMB) and which could be hacked (much more potential for a zombie demon running on the file server, that on the light-bulb).
Have the OS of the fridge/TV/whatever baked into the chip somehow (physically baked, or write-once EPROM or whatever).
Just as a side-note, for information:
EPROM : erase-able programmable read-only memory. (and EEPROM are electrically-erasable - as opposed to other methods like UV light).
(so you would need to drop the first E).
I'm probably missing something here, though.
There are 2 different problem:
TL;DR: exploitable bugs permanently burning into ROM ; lower cost of production allowing last-minute firmware changes.
I.
- yes, if the firmware is in a non-re-programmable ROM, an attacker could not permanently install a backdoor on your smart-LED-lightbulb.
- but if the smart-LED-lightbulb's firmware has a known vulnerability, an attacker could use it to take over the currently running linux server in RAM. The attacks won't survive a reboot (un-screwing the ligh-bulb ?) but as long as the bulb is powered and its server is running, maliciously injected code could be running.
- so you would need a way to upgrade the firmware to something more secure. On a bigger gizmo such thing could be possible by swapping socketed ROM chips (that's how I received an upgrade to my eMagine 3D Visor Z800 HMD - they shipped me a small ROM chip and pincer to help swapping them).
But given the tendencies of modern ultra-tiny-sized gizmos that is going to be hard
(common: light bulbs. Modern LED bulbs hide nearly all their electronics inside the screw. A socketed field-replaceable ROM chip is nearly as big as all these electronics)
(and that's not considering things like SD cards which contain a wireless linux file server - like PQI, Toshiba, etc. the whole gizmo is *smaller* than most socketable ROM chips).
II.
- nowadays the total cost of production of a gizmo using some EEPROM or eMMC is much lower.
Yup the hardware itself is probably slightly more expensive than ROM.
BUT having something that is easy field upgradeable means that the firmware can be hastily written in parallel at the same time as the hardware is produced, can be fixed in last minute until it's more or less functional and then flash it on the production hardware as it leaves assembly, just before packing into its box. This makes much lower production costs.
(Due to the easier dev cycles)
As opposed of needing a fully ready ROM with the firmware permanently burned into it as you start producing the hardware. (Needs to be already ready and debugged at the moment you start ramping up production. Meaning that you need several cycles of prototypes before to develop the ROM).
Or trying to make a gadget that can accept both EEPROM (in the dev prototype) and can be swapped with a ROM without much further hardware re-design in the final production device.
Main reason number 1 :
"automatic security updates" isn't such an attracting key point to put on a box to get more consumer.
But "this devices has 2x more pixels than the competition and you can control it from a smartphone app" is.
(And a corollary: A gizmo that gets updated regularily will get fixed and new feature for a longer time.
This require work from the company (paying devs)
This means fewer units sold to replace obsolete models)
Main reason number 2 :
Just wait until hackers find way to spoof update source, and use it as a way to install their shit on your IoT gadget
(e.g.: that's a vulnerability that's been found on Philips Smart LED light bulbs).
Making auto-updates work correctly is HARD.
- It require advanced knowledge in cryptography
- You're at risk of TIVO-ising the gizmo if you do it wrong
- This requires that the company that makes the broken gizmo that needs a firmware upgrade be still around tomorrow. That might be the case with Microsoft, but that's hardly the case with countless asian maker of cheap no-name stuff.
That was funny : I'm laughing so loud, I'm going to berk a rib.
They bring their own snack food or hit the vending machine. Or they gorge themselves before or after work.
In addition to the junk food (snacks and industrial), there is direct effect due to the *fast eating* (insuline peak, blablabla....) disruption of daily rythm...
which can also contribute to the increased chronic stress (increased corticosteroids, etc.) which also has a bad long term effect on health.
TL;DR: the junk food itself isn't the only cause of obesity, the overstress is also a major one.
Yeah, sorry, I mistyped "beark"...
huh... "breka"....
no... "braek"...