Oh, yes - making policy and decisions based on evidence as opposed to ideology - wild indeed.
I'm buckled in tightly with a 5 point harness; I'm ready for this ride.
I worked at IBM at the time (I designed and wrote a good chunk of the C/C++ compiler back-end used for OS/2), and this is quite true -- but it was aided and abetted by IBMs inability to sell OS/2 outside their traditional corporate markets. OS/2 is sadly dead and not relevant today, and has been in this state since at least 1995.
That compiler was an interesting story -- we (the OS/2 back-end team) were told to write an RPG compiler back end for OS/2 (this was back in 1989). That didn't seem like much fun, but the IR (W-Code) was the same as the one used by the C & C++ compilers for the mainframes. So we decided to make the back-end support C & C++ too -- because that *was* fun. When there was the falling out between MS and IBM, we had a working C and C++ compiler for OS/2. I can still remember getting hello.c running, then dhrystone, and not much later bootstrapping the compiler itself.
If we define the genome being searched as the pool, and the string being searched for as the key;
The paper could be completely correct when there is no reuse of the pool or keys. If you search the same pool for multiple different keys I can think of ways to pre-process the pool such that the first search + pre-process time still obeys the performance constraints their paper outlines, but subsequent searches of the same pool for a different key could happen in O log n time, or even constant time.
Will they accept liability for any damages caused as a consequence of commands on the CAN bus originating from or passing through their device? If yes, put it in writing. If no, it's not getting on the CAN bus of my vehicle.
I think the grandparent post is completely wrong. We need to fight this on 2 fronts: Technically with encryption *everywhere* (even dram contents -- a DMA controller / IO processor should *never* see plaintext), and politically -- advocating against the surveillance state, voting for politicians who reign it in where ever possible.
(In Canada, in my opinion, this means your obvious choice in the next election is the NDP. They took Alberta, they can take Ottawa.)
Breaking the "rules" as the grandparent post advocates will be *very* counter productive, and will only invite *more* abuses, not less.
Even the *cables* and patch cords can have bugs hidden in the connectors. Trust *nothing*. Encrypt everything -- I think outside sram caches on the CPU there should be no unencrypted data at all -- even dram contents should be encrypted.
Of course Key generation and distribution will be the soft underbelly for NSA, CSEC, GCHQ et al to feast on.
But as you point out, give yourself the "reasonable expectation of privacy" that encrypting everything will allow you to claim in court. Force them to tip their hand with actions. Make "parallel" construction so hard it looks laughably obvious. Make un-targeted surveillance prohibitively expensive. Make targeted spying hard enough and costly enough that they'll only use it against real adversaries and not their own citizens and dissidents / political opposition.
It seems to be the only answer and the only way we'll hold on to the freedoms that so many of our grandparents fought, bled, and died for.
He was using #8 shot. The range with a 30 degree muzzle elevation for #8 is 100 yards. If the drone was at 200 feet altitude, and that much downrange (angle would be 45 degrees) the distance would be just under 100 yards -- I think if the altitude of 200 is correct (big if) these tables show that it was at the very limit of the range of #8 shot.
I think it's far more likely that the drone was at around 100 feet or less above ground, and within 100 to 150 feet of the shooter. Even aviation grade barometric altimeters are often out by as much as 25 feet, and must be set for the ambient pressure (which drifts).
He was using #8 birdshot.
The lead of #8 shot are *tiny* little balls. -- around 1mm in size. I've been hit by falling #8 shot -- feels like light rain. It loses it's energy to air resistance very quickly. 200 feet of altitude, plus around that much downrange distance makes the range around 280 -- it seems unlikely for #8 shot to do much damage at that range.
Altitude is hard to measure with accuracy without using a radar altimeter (calibrated at that) -- GPS is +- 100 feet at best in altitude. Aviation grade barometric can be +- 25 feet, assuming the reference pressure is set accurately, *and* the ambient pressure does not drift (which it always does -- and why pilots always adjust their altimeter to the setting for a given airport -- the tower always includes that setting when talking to an incoming aircraft.)
Video evidence from the drone, along with camera information (FOV, focal length) would allow a far more accurate determination. So where is the video?
I'm Canadian -- I can't vote in American elections.
I can and do vote here in Canada, and in our upcoming election we have an option (NDP) who have promised to repeal the horribly flawed bill C51 (https://en.wikipedia.org/wiki/Anti-terrorism_Act,_2015). I encourage all like minded Canadians to get out and vote this fall.
I didn't say it wasn't getting better (mainly through better safety features and better design in cars), but that spending money on the security state is an incredibly inefficient way to make people safer and save lives. Doing almost anything *other* than just lighting the money on fire (you know -- sending a message:-) would likely be a more effective way to make people safer.
If that were actually true that saving lives or keeping people safe were their true priority, they could be vastly more effective by spending their money on reducing the highway traffic fatality rate. Over 30,000 people die on the roads of America every year. Reduce that by 10% and you'll save the equivalent of a 9/11 attack *every* year.
Of course safety and saving lives is not their primary purpose -- it's entrenching their power structures. The ability to pry into everyone's communications and files is (in their opinion) essential to that.
From Musk: There was an overpressure event in the upper stage liquid oxygen tank. Data suggests counter intuitive cause.
More info after a thorough fault tree analysis.
(I left my froot-loops in the stage 2 oxygen tank -- sorry about that Elon.)
I was thinking about whether they planted a self propagating back-door into LLVM/CLANG, but that seems fragile as both CLANG and LLVM can be compiled with other compilers (recent versions of MSVC and GCC for example) -- that would likely clear out a hidden back door unless they have compromised *all* the compilers. (And I certainly wouldn't put that past them.)
Interesting -- why are you "rebuilding" the team? The events leading to that may (or may not -- what do I know?) have something to do with the quality of your candidates.
As an aside, I worked on a C++ compiler (20 years ago at IBM), but it was the code generator & optimizer. There are plenty of moving parts in a C++ compiler that are pretty far away from C++ features like templates and stl (exceptions and lambdas on the other hand do poke their way pretty deep). You have to go and learn them -- working on a compiler back-end written largely in C (or the C like subset of C++) will not teach them to you. But I can still to this day read a hex dump and disassemble x86 instructions in my head. (not as quickly or fluently for less commonly used encodings as I used to, I'll admit)
But I'm close to the 50 year old mark -- I'm pretty grateful to have an interesting and rewarding job -- I'm quite happy that I'm not looking for work these days.
(Although Apple pings me a couple of times a year:-)
I watched this movie recently, and I had all but forgotten "All You Zombies" -- while watching it I realized the story seemed very familiar, and when one character uses the phrase "All You Zombies" it all came crashing back. (I last read it 35 years ago)
It is easily the best film treatment of any Heinlein work I've seen -- not that this sets the bar all that high -- but it was a good movie -- IMDB rates it at 7.5, and I'd agree with that.
The acting is *very* good, particularly from Sarah Snook.
The story itself was *way* ahead of it's time in many ways.
Slashdot Mirror
It's fascinating to observe -- this must be what it was like in the early 30's in Germany, watching the fascists rise to power.
I'm waiting for him to talk about "solutions" to the "Muslim problem" -- final ones, even.
Oh, yes - making policy and decisions based on evidence as opposed to ideology - wild indeed. I'm buckled in tightly with a 5 point harness; I'm ready for this ride.
I worked at IBM at the time (I designed and wrote a good chunk of the C/C++ compiler back-end used for OS/2), and this is quite true -- but it was aided and abetted by IBMs inability to sell OS/2 outside their traditional corporate markets. OS/2 is sadly dead and not relevant today, and has been in this state since at least 1995.
That compiler was an interesting story -- we (the OS/2 back-end team) were told to write an RPG compiler back end for OS/2 (this was back in 1989). That didn't seem like much fun, but the IR (W-Code) was the same as the one used by the C & C++ compilers for the mainframes. So we decided to make the back-end support C & C++ too -- because that *was* fun. When there was the falling out between MS and IBM, we had a working C and C++ compiler for OS/2. I can still remember getting hello.c running, then dhrystone, and not much later bootstrapping the compiler itself.
That was a long time ago.
If we define the genome being searched as the pool, and the string being searched for as the key; The paper could be completely correct when there is no reuse of the pool or keys. If you search the same pool for multiple different keys I can think of ways to pre-process the pool such that the first search + pre-process time still obeys the performance constraints their paper outlines, but subsequent searches of the same pool for a different key could happen in O log n time, or even constant time.
If they confirm they have spied on you, does this give you legal standing to sue? If so, expect them to neither confirm nor deny anything.
Lawrence was the smartest character in that film.
The can bus is directly exposed on the pins of the OBD2 port.
Will they accept liability for any damages caused as a consequence of commands on the CAN bus originating from or passing through their device? If yes, put it in writing. If no, it's not getting on the CAN bus of my vehicle.
I think the grandparent post is completely wrong. We need to fight this on 2 fronts: Technically with encryption *everywhere* (even dram contents -- a DMA controller / IO processor should *never* see plaintext), and politically -- advocating against the surveillance state, voting for politicians who reign it in where ever possible.
(In Canada, in my opinion, this means your obvious choice in the next election is the NDP. They took Alberta, they can take Ottawa.)
Breaking the "rules" as the grandparent post advocates will be *very* counter productive, and will only invite *more* abuses, not less.
Even the *cables* and patch cords can have bugs hidden in the connectors. Trust *nothing*. Encrypt everything -- I think outside sram caches on the CPU there should be no unencrypted data at all -- even dram contents should be encrypted.
Of course Key generation and distribution will be the soft underbelly for NSA, CSEC, GCHQ et al to feast on.
But as you point out, give yourself the "reasonable expectation of privacy" that encrypting everything will allow you to claim in court. Force them to tip their hand with actions. Make "parallel" construction so hard it looks laughably obvious. Make un-targeted surveillance prohibitively expensive. Make targeted spying hard enough and costly enough that they'll only use it against real adversaries and not their own citizens and dissidents / political opposition.
It seems to be the only answer and the only way we'll hold on to the freedoms that so many of our grandparents fought, bled, and died for.
Lrf, lbh unir gb rapelcg rirelguvat orpnhfr lbh pna'g rira gehfg n argjbex lbh pbzcyrgryl pbageby -- gurer ner ohttrq pnoyrf (rgurearg naq hfo) naq onpx-qbbef va ebhgref rgp. Rira vs gur jubyr guvat vf haqre lbhe pbageby, lbh unir gb rapelcg nyy qngn -- ng erfg be va-zbgvba. V ZVTUG gehfg gur ba-puvc pnpurf, ohg qenz fubhyq or rapelcgrq nybat jvgu rirelguvat ryfr. Bs pbhefr xrl trarengvba naq qvfgevohgvba jvyy or gur fbsg haqreoryyl.
He was using #8 shot. The range with a 30 degree muzzle elevation for #8 is 100 yards. If the drone was at 200 feet altitude, and that much downrange (angle would be 45 degrees) the distance would be just under 100 yards -- I think if the altitude of 200 is correct (big if) these tables show that it was at the very limit of the range of #8 shot. I think it's far more likely that the drone was at around 100 feet or less above ground, and within 100 to 150 feet of the shooter. Even aviation grade barometric altimeters are often out by as much as 25 feet, and must be set for the ambient pressure (which drifts).
Ok, my size estimate is slightly off -- standard US #8 birdshot is 0.09" in diameter, or 2.2mm, each weighing around 69 milligrams. (assuming lead)
He was using #8 birdshot. The lead of #8 shot are *tiny* little balls. -- around 1mm in size. I've been hit by falling #8 shot -- feels like light rain. It loses it's energy to air resistance very quickly. 200 feet of altitude, plus around that much downrange distance makes the range around 280 -- it seems unlikely for #8 shot to do much damage at that range. Altitude is hard to measure with accuracy without using a radar altimeter (calibrated at that) -- GPS is +- 100 feet at best in altitude. Aviation grade barometric can be +- 25 feet, assuming the reference pressure is set accurately, *and* the ambient pressure does not drift (which it always does -- and why pilots always adjust their altimeter to the setting for a given airport -- the tower always includes that setting when talking to an incoming aircraft.) Video evidence from the drone, along with camera information (FOV, focal length) would allow a far more accurate determination. So where is the video?
I can and do vote here in Canada, and in our upcoming election we have an option (NDP) who have promised to repeal the horribly flawed bill C51 (https://en.wikipedia.org/wiki/Anti-terrorism_Act,_2015). I encourage all like minded Canadians to get out and vote this fall.
I didn't say it wasn't getting better (mainly through better safety features and better design in cars), but that spending money on the security state is an incredibly inefficient way to make people safer and save lives. Doing almost anything *other* than just lighting the money on fire (you know -- sending a message :-) would likely be a more effective way to make people safer.
If that were actually true that saving lives or keeping people safe were their true priority, they could be vastly more effective by spending their money on reducing the highway traffic fatality rate. Over 30,000 people die on the roads of America every year. Reduce that by 10% and you'll save the equivalent of a 9/11 attack *every* year.
Of course safety and saving lives is not their primary purpose -- it's entrenching their power structures. The ability to pry into everyone's communications and files is (in their opinion) essential to that.
From Musk: There was an overpressure event in the upper stage liquid oxygen tank. Data suggests counter intuitive cause. More info after a thorough fault tree analysis. (I left my froot-loops in the stage 2 oxygen tank -- sorry about that Elon.)
https://firstlook.org/theinter...
I'm not entirely sure that I don't fail to completely disagree with you.
I was thinking about whether they planted a self propagating back-door into LLVM/CLANG, but that seems fragile as both CLANG and LLVM can be compiled with other compilers (recent versions of MSVC and GCC for example) -- that would likely clear out a hidden back door unless they have compromised *all* the compilers. (And I certainly wouldn't put that past them.)
(Waves to friendly NSA/CIA/CSIS/GCHQ analyst.)
Interesting -- why are you "rebuilding" the team? The events leading to that may (or may not -- what do I know?) have something to do with the quality of your candidates.
As an aside, I worked on a C++ compiler (20 years ago at IBM), but it was the code generator & optimizer. There are plenty of moving parts in a C++ compiler that are pretty far away from C++ features like templates and stl (exceptions and lambdas on the other hand do poke their way pretty deep). You have to go and learn them -- working on a compiler back-end written largely in C (or the C like subset of C++) will not teach them to you. But I can still to this day read a hex dump and disassemble x86 instructions in my head. (not as quickly or fluently for less commonly used encodings as I used to, I'll admit)
But I'm close to the 50 year old mark -- I'm pretty grateful to have an interesting and rewarding job -- I'm quite happy that I'm not looking for work these days.
(Although Apple pings me a couple of times a year :-)
They use their state's seizure laws where the proceeds don't go directly into the police beer fund.
Next question.
I watched this movie recently, and I had all but forgotten "All You Zombies" -- while watching it I realized the story seemed very familiar, and when one character uses the phrase "All You Zombies" it all came crashing back. (I last read it 35 years ago)
It is easily the best film treatment of any Heinlein work I've seen -- not that this sets the bar all that high -- but it was a good movie -- IMDB rates it at 7.5, and I'd agree with that.
The acting is *very* good, particularly from Sarah Snook.
The story itself was *way* ahead of it's time in many ways.
Yes, nothing, but with the "memory" of something. :-)