I have a friend who uses the site. His wife uses it, too. They like doing it with other people every so often, to spice things up. They are open about it with each other. I can't imagine that they are the only ones. They are perhaps in the minority since their relationship is good enough that they can be open about such things with each other, but still: they are not the only ones. They didn't get a letter yet, but they are both quite worked up about what happens if they do. They look forward to it, they decided to play the extortionists as long as they can, and mess their schemes up as much as possible. Their friends all know what's up, and their family too, for the most part, so the blackmail opportunity simply doesn't exist: they've got nothing to hide.
That the driver will, as automation increases, stop paying attention even faster and thus have increasing numbers of accidents.
This very problem is a direct cause of quite a few aircraft crashes, so you're just not understanding it, but Google is.
there is nothing preventing the automation from simply being offline until the last moment when it can prevent the collision
We don't need autonomy to prevent collisions. We need autonomy because commuting, for the most part, is a horrendous waste of time. If I'm in the car, I'd much rather read the e-book than listen to an audiobook, or I'd work on something. I commute for 40 minutes total each day. It'd get a lot of side projects done if I could devote two uninterrupted 20 minute chunks of time each day to something other than driving. Life only lasts so long, you know.
When I drive for pleasure, I drive for pleasure. Commuting to work isn't it.
It's incorrect to say that FFT is "using sines". FFT is using complex exponents as base functions, while DCT uses real cosine functions. The major practical difference between the two is the discontinuities at the boundaries present in FFT, but absent in DCT. That's what makes DCT easier to apply in compression jobs.
Those would be rather gross synthesis or layout errors. These kinds of "miswirings" are almost impossible with properly modularized HDL. If you get the "memory affects registers" kind of a bug, there's something very wrong somewhere in the tools, but it's super unlikely that it'd be a design error.
Wouldn't it be simpler at that point to simply chuck the original controller and replace it with something custom? Internal combustion engine control, and usual ways of controlling and managing the machine of a tractor's complexity aren't exactly new things and don't quite require a Ph.D. in controls engineering. I'd say it's something a decent undergrad should be able to prototype in a couple of months, I'd hope...
I think that the furnace controller I have does allow that, but it actually requires more wires if you'd want the t-stat to control all the features that are potentially available (2-stage pump, 4-speed fan, humidifier, heat/cool, evap defrost, condenser defrost, etc.). With CAN, you have two wires for the data, and two for power.
It's usually CAN or RS-485 and the packets are dead simple. Calling Carrier's Infinity system "proprietary crap" is like lamenting the arrival of OBD-II. Retarded. I don't use Carrier's t-stat anyway, the hardware for that one was truly crappy, and the firmware constrained by the typical big-corporation nonsense. But it did do what it was supposed to do, and it was way more functional than dumb t-stats are.
Right now I have a multi-zone system just by adding some air valves to the existing system, and putting another thermostat in the hallway upstairs. Everything still communicates over the same bus, and everything hooks up together over 4 wires (power+CAN). If I was starting with a furnace with on/off signaling, I'd have to replace the furnace controller board, and possibly the heat pump controller too (if it had one).
I personally really like the idea of a heat pump that has a high- and low-side pressure sensor, a motor current sensor, two air temp sensors, and a little board that puts the numbers on the CAN. Makes for real easy diagnostics.
My HVAC has four wires between the furnace and the thermostat: 24VAC and a CAN pair. I'd consider this a gold standard way of doing it, frankly said. The thermostat is able to provide full component information: I can see the S/N and model of all replaceable components, the options, I can see real-time diagnostics, force extra defrost cycles, etc. - just like in any modern car.
This is simple. CAN is a standard peripheral on many microcontrollers. It's easy to use. There are lots of tools available to talk to the bus. For small, low-bandwidth control systems, CAN is a great choice.
Advocating on/off signaling for HVAC is like asking for carburetors and pre-OBD-II car ECUs to come back. It makes zero sense.
BTW, the protocols that run on top of CAN are either standard or are trivial to reverse-engineer. I haven't been running Carrier's own t-stat for a good while now. If you have working knowledge of some higher CAN-based protocol like CANopen, it shouldn't take longer than an afternoon or two to get the basic functionality going from a USB<->CAN dongle of your choice.
Even if they start doing some sort of cryptographic authentication of endpoints, like is done for some car components, they'll likely have plenty enough implementation bugs that those with the know-how will figure it out anyway. A Carrier Infinity system is way more hacker-friendly than one with on/off signaling. Way more bang for the buck, so to speak. I personally find it shameful that Nest hasn't made it a standard feature to interface with the most popular proprietary HVAC comms out there. It doesn't take a rocket scientist to do. From the end-user perspective, it's less wires and way more functionality, so I'd call it win-win.
Almost every home heating and cooling system operates on demand from a t-stat that runs on 24 volts ac low voltage.
Yeah, old or entry-level shit that nobody with a sane mind would get in the first place unless forced to. All less-than-basic furnaces don't use the simple on/off signaling. You'll get these in rented apartments, but I'd hope that most homes with HVAC systems replaced in the last 10 years will not have this old shit anymore.
That's the real deal: the Nest can only replace dumb thermostats on the lowest-end HVAC systems. All more-than-bare-bones HVAC systems use a proprietary protocol to communicate with its own smart thermostat already. If these thermostats fail, all you are exposed to is four wires: two have 24V on them, the other two have CAN or maybe RS-485. Now, thankfully, these protocols are very simple to reverse-engineer, so I have dispensed with the factory Infinity thermostat for years now, but still: it's not as easy as shorting two wires together, and you need a working thermostat to see the protocol first. Unless you want to reverse-engineer or re-write furnace firmware, that is. I'm contemplating redoing the furnace firmware and moving to some standard protocol like CANopen but I haven't found any HVAC profiles for it yet:(
This of course is true, but what is handled by the graphics driver is not memory, but OpenGL primitives like buffers. The OS has absolutely no bearing on any of that, it's up to the driver to do the right thing. Just as a graphics driver can pass unclean buffer primitives around, a serial driver bug might not clear a communications buffer, or a fancy keyboard driver with OLED displays in the keys might leak the data from your porn setup where the function keys have pics of your fave pornstars on them:)
Basically, there's no way for the OS to guarantee that a driver won't subvert the security. By no way I mean neither a practical way nor even a theoretical way, unless the feature set of the hardware was very limited.
The OS has the responsibility to ensure that there is no unintentional sharing of data between processes.
In general, it's impossible for the OS to guarantee that, since drivers are nominally accessible by multiple processes at once. Say a serial port driver has a bug and doesn't wipe the buffer between closing and reopening of the device: OS can't help here, it's a driver bug that leaks data between processes here. Same goes for graphics drivers.
Here's what happens: GPU memory is allocated in chunks of wildly varying sizes. To maximize the amount of usable GPU memory, the objects (buffers) owned by various clients of the driver can be allocated adjacent to each other. I.e. the driver doesn't (and shouldn't) have higher-level subdivisions, such as pages, that are owned by one process only. The driver bug is that the GPU memory a buffer is using not cleared before being passed to a different process. This is a very performant sidechannel that leaks data between supposedly isolated processes. This is very bad indeed.
The Chrome bug is that it accepts buffers and doesn't clear them before selecting them as textures.
Windows does enforce clearing of newly allocated memory, including on the GPU
It doesn't. Really. It only clears the paged memory when pages change ownership or are first initialized. A set of pinned pages is retained by the graphics driver for as long as the driver wishes, and it's completely up to the driver to clear those when the logical ownership of the resource stored on any given page is assigned to a new process. Furthermore, it might not even be that a single page in the GPU memory belongs to one process only. It might store textures or other buffers from two or more processes, after all. It's really up to the driver to do the right thing here.
The OS has very little control here, since the memory is not handled as memory, but as graphics resources. What's passed around isn't memory pages but texture buffers etc. These are managed by the graphics driver, and the OS expects the driver to do the right thing. I don't even think it's possible for the OS to handle this properly without there being clear API protocols that give the OS enough knowledge about what resources are passed around, and when they should be zero-initialized.
This is a huge side-channel that can be exploited to communicate between "isolated" processes. You can e.g. have some malicious javascript working on an off-screen webgl context, inside of a sandbox, and it can use this to communicate with malware running elsewhere on the same host. This is pretty bad IMHO.
LOL, no. To be in control of a basic car with four disc brakes, you'd need four brake pedals, or a joystick driving valves in a hydraulic manifold to direct the braking effort. Note the absence of such in the "me in control!" cars that you allude to. In fact, modern cars with electronic stability control at least give you some semblance of this by using the steering angle to produce steer torques from the braking system. You can't do that on a stock legacy car.
I happen to have owned a car where I have made the directional braking mod, as a completely hydromechanical addition on top of the existing ABS-less braking system. Having driven it for 5 years, all I tell you is that yes, you're deluded about having ultimate control of a four-brake car with just one brake pedal for the input. The experience is unforgettable, and I only wish this was a standard feature on muscle/drift cars.
Personally, I quite like my SUV with electronic stability control, thanks.
If you want a password manager written in Javascript, there are ways of doing it properly. Clipperz.is is a good example. First and foremost, it is open source. Secondly, it lets you export a read-only copy of the application as a single, self-contained html file that you can run locally and export from again. Or you can export cleartext json+html if you wish to transfer the data elsewhere. Furthermore, everything is encrypted by default and no cleartext leaves your browser. Cleartext is extracted on as-needed basis, so even if you did a RAM dump from a running instance in a browser, all you'd get is the currently open entry and the some of the session keys that would require further reverse-engineering to be of any use. And they have had a third-party security audit done that identified a few problems that were promptly fixed.
You can run it on your own backend, or on Clipperz's.
But perhaps I should stay quiet lest someone like Trend Micro buys them out and fucks it for everyone.
That's great to know! Is such depth enough to do meaningful random mutation detection without dealing with a lot of sequencing errors? I don't really know how it works, that's why I ask.
If your perspective is out of touch with reality, then you are definitely on the hook for the results of your ignorance. "Butbut I thought the vaccines were really bad!" Nope, real life doesn't work that way.
At the end of the day, people die, so your argument is that if the parents kill their kids and other parents due to collateral damage it's OK, but when a madman does it - it's not OK? The fuck of an argument is that?
I'm pretty liberal, but I fail to see how being liberal implies involving the government overlords in every fucking thing? The whole point of liberalism is to live and let live, at least that's my interpretation. Perhaps I'm wrong:(
Slashdot Mirror
I have a friend who uses the site. His wife uses it, too. They like doing it with other people every so often, to spice things up. They are open about it with each other. I can't imagine that they are the only ones. They are perhaps in the minority since their relationship is good enough that they can be open about such things with each other, but still: they are not the only ones. They didn't get a letter yet, but they are both quite worked up about what happens if they do. They look forward to it, they decided to play the extortionists as long as they can, and mess their schemes up as much as possible. Their friends all know what's up, and their family too, for the most part, so the blackmail opportunity simply doesn't exist: they've got nothing to hide.
That the driver will, as automation increases, stop paying attention even faster and thus have increasing numbers of accidents.
This very problem is a direct cause of quite a few aircraft crashes, so you're just not understanding it, but Google is.
there is nothing preventing the automation from simply being offline until the last moment when it can prevent the collision
We don't need autonomy to prevent collisions. We need autonomy because commuting, for the most part, is a horrendous waste of time. If I'm in the car, I'd much rather read the e-book than listen to an audiobook, or I'd work on something. I commute for 40 minutes total each day. It'd get a lot of side projects done if I could devote two uninterrupted 20 minute chunks of time each day to something other than driving. Life only lasts so long, you know.
When I drive for pleasure, I drive for pleasure. Commuting to work isn't it.
It's incorrect to say that FFT is "using sines". FFT is using complex exponents as base functions, while DCT uses real cosine functions. The major practical difference between the two is the discontinuities at the boundaries present in FFT, but absent in DCT. That's what makes DCT easier to apply in compression jobs.
No, they don't. Yes you can. Maybe - meh.
Those would be rather gross synthesis or layout errors. These kinds of "miswirings" are almost impossible with properly modularized HDL. If you get the "memory affects registers" kind of a bug, there's something very wrong somewhere in the tools, but it's super unlikely that it'd be a design error.
Do you have a Czar of Bandgaps, and do you dread temperature-dependent startup problems yet? :)
Thanks! I've learned something new.
Wouldn't it be simpler at that point to simply chuck the original controller and replace it with something custom? Internal combustion engine control, and usual ways of controlling and managing the machine of a tractor's complexity aren't exactly new things and don't quite require a Ph.D. in controls engineering. I'd say it's something a decent undergrad should be able to prototype in a couple of months, I'd hope...
I think that the furnace controller I have does allow that, but it actually requires more wires if you'd want the t-stat to control all the features that are potentially available (2-stage pump, 4-speed fan, humidifier, heat/cool, evap defrost, condenser defrost, etc.). With CAN, you have two wires for the data, and two for power.
It's usually CAN or RS-485 and the packets are dead simple. Calling Carrier's Infinity system "proprietary crap" is like lamenting the arrival of OBD-II. Retarded. I don't use Carrier's t-stat anyway, the hardware for that one was truly crappy, and the firmware constrained by the typical big-corporation nonsense. But it did do what it was supposed to do, and it was way more functional than dumb t-stats are.
Right now I have a multi-zone system just by adding some air valves to the existing system, and putting another thermostat in the hallway upstairs. Everything still communicates over the same bus, and everything hooks up together over 4 wires (power+CAN). If I was starting with a furnace with on/off signaling, I'd have to replace the furnace controller board, and possibly the heat pump controller too (if it had one).
I personally really like the idea of a heat pump that has a high- and low-side pressure sensor, a motor current sensor, two air temp sensors, and a little board that puts the numbers on the CAN. Makes for real easy diagnostics.
My HVAC has four wires between the furnace and the thermostat: 24VAC and a CAN pair. I'd consider this a gold standard way of doing it, frankly said. The thermostat is able to provide full component information: I can see the S/N and model of all replaceable components, the options, I can see real-time diagnostics, force extra defrost cycles, etc. - just like in any modern car.
This is simple. CAN is a standard peripheral on many microcontrollers. It's easy to use. There are lots of tools available to talk to the bus. For small, low-bandwidth control systems, CAN is a great choice.
Advocating on/off signaling for HVAC is like asking for carburetors and pre-OBD-II car ECUs to come back. It makes zero sense.
BTW, the protocols that run on top of CAN are either standard or are trivial to reverse-engineer. I haven't been running Carrier's own t-stat for a good while now. If you have working knowledge of some higher CAN-based protocol like CANopen, it shouldn't take longer than an afternoon or two to get the basic functionality going from a USB<->CAN dongle of your choice.
Even if they start doing some sort of cryptographic authentication of endpoints, like is done for some car components, they'll likely have plenty enough implementation bugs that those with the know-how will figure it out anyway. A Carrier Infinity system is way more hacker-friendly than one with on/off signaling. Way more bang for the buck, so to speak. I personally find it shameful that Nest hasn't made it a standard feature to interface with the most popular proprietary HVAC comms out there. It doesn't take a rocket scientist to do. From the end-user perspective, it's less wires and way more functionality, so I'd call it win-win.
Almost every home heating and cooling system operates on demand from a t-stat that runs on 24 volts ac low voltage.
Yeah, old or entry-level shit that nobody with a sane mind would get in the first place unless forced to. All less-than-basic furnaces don't use the simple on/off signaling. You'll get these in rented apartments, but I'd hope that most homes with HVAC systems replaced in the last 10 years will not have this old shit anymore.
Why the heck would you need to charge these things? Don't they get power from the furnace?!
That's the real deal: the Nest can only replace dumb thermostats on the lowest-end HVAC systems. All more-than-bare-bones HVAC systems use a proprietary protocol to communicate with its own smart thermostat already. If these thermostats fail, all you are exposed to is four wires: two have 24V on them, the other two have CAN or maybe RS-485. Now, thankfully, these protocols are very simple to reverse-engineer, so I have dispensed with the factory Infinity thermostat for years now, but still: it's not as easy as shorting two wires together, and you need a working thermostat to see the protocol first. Unless you want to reverse-engineer or re-write furnace firmware, that is. I'm contemplating redoing the furnace firmware and moving to some standard protocol like CANopen but I haven't found any HVAC profiles for it yet :(
This of course is true, but what is handled by the graphics driver is not memory, but OpenGL primitives like buffers. The OS has absolutely no bearing on any of that, it's up to the driver to do the right thing. Just as a graphics driver can pass unclean buffer primitives around, a serial driver bug might not clear a communications buffer, or a fancy keyboard driver with OLED displays in the keys might leak the data from your porn setup where the function keys have pics of your fave pornstars on them :)
Basically, there's no way for the OS to guarantee that a driver won't subvert the security. By no way I mean neither a practical way nor even a theoretical way, unless the feature set of the hardware was very limited.
The OS has the responsibility to ensure that there is no unintentional sharing of data between processes.
In general, it's impossible for the OS to guarantee that, since drivers are nominally accessible by multiple processes at once. Say a serial port driver has a bug and doesn't wipe the buffer between closing and reopening of the device: OS can't help here, it's a driver bug that leaks data between processes here. Same goes for graphics drivers.
Here's what happens: GPU memory is allocated in chunks of wildly varying sizes. To maximize the amount of usable GPU memory, the objects (buffers) owned by various clients of the driver can be allocated adjacent to each other. I.e. the driver doesn't (and shouldn't) have higher-level subdivisions, such as pages, that are owned by one process only. The driver bug is that the GPU memory a buffer is using not cleared before being passed to a different process. This is a very performant sidechannel that leaks data between supposedly isolated processes. This is very bad indeed.
The Chrome bug is that it accepts buffers and doesn't clear them before selecting them as textures.
Windows does enforce clearing of newly allocated memory, including on the GPU
It doesn't. Really. It only clears the paged memory when pages change ownership or are first initialized. A set of pinned pages is retained by the graphics driver for as long as the driver wishes, and it's completely up to the driver to clear those when the logical ownership of the resource stored on any given page is assigned to a new process. Furthermore, it might not even be that a single page in the GPU memory belongs to one process only. It might store textures or other buffers from two or more processes, after all. It's really up to the driver to do the right thing here.
The OS has very little control here, since the memory is not handled as memory, but as graphics resources. What's passed around isn't memory pages but texture buffers etc. These are managed by the graphics driver, and the OS expects the driver to do the right thing. I don't even think it's possible for the OS to handle this properly without there being clear API protocols that give the OS enough knowledge about what resources are passed around, and when they should be zero-initialized.
This is a huge side-channel that can be exploited to communicate between "isolated" processes. You can e.g. have some malicious javascript working on an off-screen webgl context, inside of a sandbox, and it can use this to communicate with malware running elsewhere on the same host. This is pretty bad IMHO.
LOL, no. To be in control of a basic car with four disc brakes, you'd need four brake pedals, or a joystick driving valves in a hydraulic manifold to direct the braking effort. Note the absence of such in the "me in control!" cars that you allude to. In fact, modern cars with electronic stability control at least give you some semblance of this by using the steering angle to produce steer torques from the braking system. You can't do that on a stock legacy car.
I happen to have owned a car where I have made the directional braking mod, as a completely hydromechanical addition on top of the existing ABS-less braking system. Having driven it for 5 years, all I tell you is that yes, you're deluded about having ultimate control of a four-brake car with just one brake pedal for the input. The experience is unforgettable, and I only wish this was a standard feature on muscle/drift cars.
Personally, I quite like my SUV with electronic stability control, thanks.
If you want a password manager written in Javascript, there are ways of doing it properly. Clipperz.is is a good example. First and foremost, it is open source. Secondly, it lets you export a read-only copy of the application as a single, self-contained html file that you can run locally and export from again. Or you can export cleartext json+html if you wish to transfer the data elsewhere. Furthermore, everything is encrypted by default and no cleartext leaves your browser. Cleartext is extracted on as-needed basis, so even if you did a RAM dump from a running instance in a browser, all you'd get is the currently open entry and the some of the session keys that would require further reverse-engineering to be of any use. And they have had a third-party security audit done that identified a few problems that were promptly fixed.
You can run it on your own backend, or on Clipperz's.
But perhaps I should stay quiet lest someone like Trend Micro buys them out and fucks it for everyone.
That's great to know! Is such depth enough to do meaningful random mutation detection without dealing with a lot of sequencing errors? I don't really know how it works, that's why I ask.
If your perspective is out of touch with reality, then you are definitely on the hook for the results of your ignorance. "Butbut I thought the vaccines were really bad!" Nope, real life doesn't work that way.
At the end of the day, people die, so your argument is that if the parents kill their kids and other parents due to collateral damage it's OK, but when a madman does it - it's not OK? The fuck of an argument is that?
I'm pretty liberal, but I fail to see how being liberal implies involving the government overlords in every fucking thing? The whole point of liberalism is to live and let live, at least that's my interpretation. Perhaps I'm wrong :(