The US has imprisoned the largest percentage of their population, exploiting their labour for profit. With wealthy lobbyists pushing for ever harsher sentencing...
At best certs verify that the owner of the domain name is also the owner of the server. So why not just publish cert details in dns, secured by dnssec?
Sure, if your dns records get "hacked" somehow, you're screwed. But with how easy it is to get a cert from lets encrypt, that's already true now.
I wouldn't mind constant updates, so long as they actually worked. The problem as I see it is that Microsoft are trying to use the same workflow they've always used, just with a shorter release cycle.
Try to push as many features into trunk as you can before feature freeze. Even if they are broken.
Go through some number of test / fix cycles to iron out the things that don't work.
Release, with a whole bunch of bugs that you didn't test for and didn't find.
This is the reason we used to wait for service packs before upgrading. It gave them a chance to find and fix all more bugs.
What they *need* to do is split out individual components from their monolithic source code repo. Each with their own release cycle and quality control. Write automated tests for absolutely everything, and only merge changes into release builds when all tests pass.
The Kibble balance uses measurements of voltage, current, velocity and gravitational acceleration in order to calculate the mass that was placed on the balance. Here's the maths involved.
Then it's likely that those measured masses will be used to calibrate other equipment, as is done now with reference masses that were compared to Big K.
I tried writing a small file parsing library in rust. Maybe I wasn't doing it the "rust way", but satisfying the borrow checker felt like writing recursive templates.
How many C++ coders do you know who get templates right?
Redefining the Kilogram requires everyone to agree on the value of Planks constant, using different methods. The silicon sphere does help for this, but it's still a bit too hard to reproduce.
Take a speaker coil, push the cone up and down and measure both the velocity of the movement and the voltage produced.
Because of the way speaker coils work this allows you to derive the relationship between the current through this coil, and the force that is produced;
Force = (Voltage / Velocity) * Current.
Now drop something and measure the local acceleration due to gravity. Force equals mass * acceleration, so now you can derive the relationship between current and mass;
Mass = (Voltage / (Velocity * Gravity)) * Current [for this coil, in this room].
Well I actually *did* do something similar more than 20 years ago with some dumb terminals connected to (i think) a sunos server. Well, technically they weren't logged in at the time.
So I'd written a script to use the finger protocol on each student server, collect the IP addresses of the tty's everyone was logged in from, which I'd draw in an ascii art map of each lab.
I'd worked out that one lab of terminals had a beep pitch you could change, while the other labs would only beep at whole octaves.
And I'd worked out that all the terminals were open to remote connections while there was nobody logged in.
One day the stars aligned, I pulled up a map of this lab and there was only one guy in there. So I picked a bunch of the terminals around him and beeped out the 5 note close encounters tune.
So he comes running down the corridor to our lab saying that was awesome, who did that. And everyone pointed straight at me. Because of course if anything weird happened it was probably my fault.
While exploring the windows API's, I wrote a little program that would enumerate all the volume controls in the sound mixer, identify anything that looked like it might stop a sound from playing. It would un-mute and push every playback volume slider to 100%, play a.wav file provided from the command line, then restore the value of each control.
The office I worked in had a standard dell machine on every desk, with a built in speaker. Of course since we were packed together in a cube farm, most people had muted the volume.
For an April 1st one year, I prepared a script that would connect to each machine using PSExec from System Internals to push my small program across the network and play a clip from Close Encounters of the 3rd Kind at full blast.
If you've watched any of google's visualizations, they clearly have systems working out where the car is not allowed to drive. A cyclist waving his arms around? Paint a red line across the lane behind him in case he is trying to turn. Train crossing with other vehicles? Paint a red line this side of the crossing until the way is clear.
If the vehicle is surprised, due to some sensor failure or erratic pedestrian, I'm certain the car would just hit the brakes or change lanes if possible. Then I'd expect a small team of engineers to examine the available sensor data to work out if there was anything they could change to avoid the situation.
But will we end up with roads clogged with overly cautious self driving cars? Where do we draw the line between safety and speed?
This still feels like Microsoft are using the same development model under the hood. Go through a burst of writing new features, trying to get them into trunk before "feature freeze", not caring that they are fundamentally broken. Then go through a bug fixing phase before release. The difference is the timing of each development cycle.
They migrated to git internally, but their code base is so large that they had to write a virtual filesystem driver so developers could work on the code without cloning the history and checking it all out. Clearly, what they should be focusing on is splitting every component into a separate source code repository, each with their own release cycle. With automated testing to ensure that every release actually works.
This would be a painful & slow process, but with a solid foundation underfoot, they should be able to build new features faster.
The retpoline hack is a deliberate stack smash, to execute an indirect jump that the CPU will not speculate. Since the CPU cannot speculate it, execution *must* be slower than code from before spectre was discovered. But it does mean you can turn off *really* slow CPU mitigations.
The real trick is avoiding the need for retpoline in the first place. Make sure that indirect jumps have shortcuts for commonly executed branches that aren't affected by Spectre.
BTW, I watched a great talk about spectre, for application developers, by a clang compiler engineer who was involved in the research on spectre.
Because that's how the IEEE names standards documents as they are approved. Every letter from a-z, then like column naming in spreadsheets, every pair from aa-az has / will have a standard document that details a new improvement to WIFI.
I recently upgraded to an i7, from a CPU that was first released about 10 years prior. According to online benchmarks, my new CPU is only 5x faster at single threaded tasks. There are way more transistors in my new CPU that do more work in parallel, even within a single core. Instruction decoding, instruction decode caching, scheduling, speculating,.... That theoretical 5x speed up has more to do with throwing more transistors at the problem, not because the transistors themselves are much faster.
Slashdot Mirror
You know what has the biggest effect on house prices? Credit availability. Do you think house prices could climb if people couldn't borrow money?
The senate just passed the bill without the amendments.
Ayes 44
Noes 12
The bill is passed.
Australia’s security and intelligence agencies have legal authority to force encryption services to break the encryptions.
Shit.
And yet, the MP's have no problem using messaging apps with strong encryption themselves.
The US has imprisoned the largest percentage of their population, exploiting their labour for profit. With wealthy lobbyists pushing for ever harsher sentencing...
At best certs verify that the owner of the domain name is also the owner of the server. So why not just publish cert details in dns, secured by dnssec?
Sure, if your dns records get "hacked" somehow, you're screwed. But with how easy it is to get a cert from lets encrypt, that's already true now.
I wouldn't mind constant updates, so long as they actually worked. The problem as I see it is that Microsoft are trying to use the same workflow they've always used, just with a shorter release cycle.
This is the reason we used to wait for service packs before upgrading. It gave them a chance to find and fix all more bugs.
What they *need* to do is split out individual components from their monolithic source code repo. Each with their own release cycle and quality control. Write automated tests for absolutely everything, and only merge changes into release builds when all tests pass.
There are so many machines out there with domain names in memory, that squatting domains that are a single bit-flip away can be quite interesting.
Moving from one project to another, without bothering with support & maintenance, is exactly what valve have always done.
I can't be the only one here that goes to look for a bug that vanishes when I am doing any kind of problem.
Now THAT is Quantum Computing.
Nah, that's a heisenbug.
The Kibble balance uses measurements of voltage, current, velocity and gravitational acceleration in order to calculate the mass that was placed on the balance. Here's the maths involved.
Then it's likely that those measured masses will be used to calibrate other equipment, as is done now with reference masses that were compared to Big K.
I tried writing a small file parsing library in rust. Maybe I wasn't doing it the "rust way", but satisfying the borrow checker felt like writing recursive templates.
How many C++ coders do you know who get templates right?
Redefining the Kilogram requires everyone to agree on the value of Planks constant, using different methods. The silicon sphere does help for this, but it's still a bit too hard to reproduce.
Here's roughly how I would try to explain it.
Take a speaker coil, push the cone up and down and measure both the velocity of the movement and the voltage produced.
Because of the way speaker coils work this allows you to derive the relationship between the current through this coil, and the force that is produced;
Force = (Voltage / Velocity) * Current.
Now drop something and measure the local acceleration due to gravity. Force equals mass * acceleration, so now you can derive the relationship between current and mass;
Mass = (Voltage / (Velocity * Gravity)) * Current [for this coil, in this room].
Don't forget to include all the jokes!
Well one guy did yell and pull his headphones out of his ears. (Sorry Nick)
Well I actually *did* do something similar more than 20 years ago with some dumb terminals connected to (i think) a sunos server. Well, technically they weren't logged in at the time.
So I'd written a script to use the finger protocol on each student server, collect the IP addresses of the tty's everyone was logged in from, which I'd draw in an ascii art map of each lab.
I'd worked out that one lab of terminals had a beep pitch you could change, while the other labs would only beep at whole octaves.
And I'd worked out that all the terminals were open to remote connections while there was nobody logged in.
One day the stars aligned, I pulled up a map of this lab and there was only one guy in there. So I picked a bunch of the terminals around him and beeped out the 5 note close encounters tune.
So he comes running down the corridor to our lab saying that was awesome, who did that. And everyone pointed straight at me. Because of course if anything weird happened it was probably my fault.
While exploring the windows API's, I wrote a little program that would enumerate all the volume controls in the sound mixer, identify anything that looked like it might stop a sound from playing. It would un-mute and push every playback volume slider to 100%, play a .wav file provided from the command line, then restore the value of each control.
The office I worked in had a standard dell machine on every desk, with a built in speaker. Of course since we were packed together in a cube farm, most people had muted the volume.
For an April 1st one year, I prepared a script that would connect to each machine using PSExec from System Internals to push my small program across the network and play a clip from Close Encounters of the 3rd Kind at full blast.
Intel have done a lot of work on the parts of the kernel that interface with their hardware. Graphics drivers, networking, ....
If you've watched any of google's visualizations, they clearly have systems working out where the car is not allowed to drive. A cyclist waving his arms around? Paint a red line across the lane behind him in case he is trying to turn. Train crossing with other vehicles? Paint a red line this side of the crossing until the way is clear.
If the vehicle is surprised, due to some sensor failure or erratic pedestrian, I'm certain the car would just hit the brakes or change lanes if possible. Then I'd expect a small team of engineers to examine the available sensor data to work out if there was anything they could change to avoid the situation.
But will we end up with roads clogged with overly cautious self driving cars? Where do we draw the line between safety and speed?
This still feels like Microsoft are using the same development model under the hood. Go through a burst of writing new features, trying to get them into trunk before "feature freeze", not caring that they are fundamentally broken. Then go through a bug fixing phase before release. The difference is the timing of each development cycle.
They migrated to git internally, but their code base is so large that they had to write a virtual filesystem driver so developers could work on the code without cloning the history and checking it all out. Clearly, what they should be focusing on is splitting every component into a separate source code repository, each with their own release cycle. With automated testing to ensure that every release actually works.
This would be a painful & slow process, but with a solid foundation underfoot, they should be able to build new features faster.
The retpoline hack is a deliberate stack smash, to execute an indirect jump that the CPU will not speculate. Since the CPU cannot speculate it, execution *must* be slower than code from before spectre was discovered. But it does mean you can turn off *really* slow CPU mitigations.
The real trick is avoiding the need for retpoline in the first place. Make sure that indirect jumps have shortcuts for commonly executed branches that aren't affected by Spectre.
BTW, I watched a great talk about spectre, for application developers, by a clang compiler engineer who was involved in the research on spectre.
Like the textbook model of supply and demand? Which assumes that;
All of which is demonstrably stupid and doesn't match the real economy.
Because that's how the IEEE names standards documents as they are approved. Every letter from a-z, then like column naming in spreadsheets, every pair from aa-az has / will have a standard document that details a new improvement to WIFI.
This is the "right way" to test those braking features; The Collapsile Crash Test Robot Car
I recently upgraded to an i7, from a CPU that was first released about 10 years prior. According to online benchmarks, my new CPU is only 5x faster at single threaded tasks. There are way more transistors in my new CPU that do more work in parallel, even within a single core. Instruction decoding, instruction decode caching, scheduling, speculating, .... That theoretical 5x speed up has more to do with throwing more transistors at the problem, not because the transistors themselves are much faster.