Those the the reasons I like Ada, or rather Ada written in VHDL, what with VHDL being pretty much a superset. It's a superb modeling language. You can easily constrain all state to be what the thing being modeled. But it's a fugly language and only the hard nosed people building chips had the stomach to take it. Which is why we are here today. Pity the people trying to build test benches in Verilog and having to investing in expensive test languages after finding how useless it is. The irony is VHDL is a pretty sucky HDL full of verbosity and boilerplate when you just want to describe binary logic.
"Right now we're just beta testing the St. Louis area, and we're getting positive hits," he says (meaning ads that match hotel-room photos in the database).
"Hits" or "False Positives" as they are known in statistics.
We get a current employee list from HR quarterly, and all employee changes immediately. Any account, including service accounts, that don't have a clear owner and purpose are disabled. There's no way an invalid user should have been in place for years.
Columbia make overpriced clothing, not overpriced software. Maybe they aren't so focused on IT security.
That isn't because most applicants suck. That is because sucky applicants apply for a lot more jobs and interview many more times. Non sucky engineers tend to interview a lot less. So when you're on the interviewer, you see more sucky candidates.
If you want to see a higher quality of engineer walk in the door, offer more money and a nice work place with reasonable levels of autonomy.
It is unreasonable to expect mechanical engineer to be able to diagnose network issues, just like it would be unreasonable to expect network engineer to know how to calculate shear forces going through a support beam.
Funny you mention the latter. I would worry about you if you were unable to calculate sheer forces going through a beam. This stuff is high level enough that it is nothing more than typing numbers into a prepared excel spreadsheet.
Now whether you know the answer or not is entirely different. I would most definitely expect a mechanical engineer to be able to diagnose network issues. I don't expect them to be able to perfectly design it from the ground up or optimise the loading network wide but there is a very large scope of IT that we should expect people in general to be able to do.
My first paid job 30+ years ago was to port a mechanical engineer's basic code from a Sinclair QL to the Apple ][ called "Columns to BS449". So I'm pretty good with columns, not so much with beams.
All the companies I have been in that were small enough to not have dedicated IT specialists were awesome workplaces. They also didn't have password rules or office rules or messed up firewall proxies or the massive weight of corporate bureaucracy. You got to operate the coffee machine yourself rather than being at the mercy of an underpaid contract worker trained in food safety.
I used to work with a 60+ year old analog electronics engineer. He neither knew nor cared anything networks or modern ways of working but with pen, paper and a lab he would build up a SMPS for whatever the current product was and then refine the shit out of it until it was quiet, reliable, efficient and small. He had a side business selling interesting audio electronics products.
You don't dismiss that wealth of experience and talent because they don't care about netmasks and gateways. You hire it and retain it. If anyone had a problem, we helped each other out.
Yes. I wasn't saying it's not useful or interesting. I'm saying the benefits of speeding it up a bit are tiny compared to the costs of a quantum computer.
1% is a pretty serious flaw. If it was my product I would be concerned as to whether or not it was a progressive failure and they're all going to fail in the end.
Never heard the phrase "run it up the flagpole" but if you find the question "how will this scale?" annoying, you may want to choose a new line of business.
Indeed. It's a primary question you need to answer when proposing any new technology or solution. If you ask me how my stuff scales, I'll give you the area/power/performance tradeoffs that are available in the design parameterization.
That article supports my assertion that there aren't many compelling quantum algorithms unless you are trying to break crypto.
Lattice crypto mentioned in the article is not a quantum algorithm. It's a class of classical algorithms, some of which claim to be secure against quantum computers. They are also demonstrably hard to get right so they are secure against normal computers.
The paper it references "Exponential Lower Bounds for Polytopes in Combinatorial Optimization" is about optimization problems, which is exactly one of the boring things that the DWave machine does less efficiently than classical computers and if it were a solved problem it would at best find some slightly more optimal solutions to things like the traveling salesman problem, which might shave a few minutes of your next flight, but not nearly as much as plane companies building better planes would.
I've yet to see a compelling application beyond breaking crypto or showing that quantum computers can work - which is a little circular.
There's nothing particularly compelling. Quantum computers make great science and great science yields benefits. If it does, I'm skeptical that it will be because they could solve a BQP problem efficiently.
My real problem is with the breathless tone of the article that perpetuates misconceptions.
(1 & 2) Yes. This is a nit I have with people who describe quantum interactions as reversible, because you can run the equations for the wave equations backwards. You can, as long as you ignore every other bit of energy in the universe but everything we know tells us you can't ignore thermodynamics when it comes to causality. Things are not reversible. That we have failed to implement useful quantum computers one data point consistent with this view.
(3) I hadn't considered side channels on quantum computers (to be fair as a result of my job, I've considered entangled adversary secure entropy extractors, which is similar but goes in the other direction) so thank you, something to think about.
I'm not sure in what way we disagree. My comments were all to do with the fashion in which people's response to the cryptographic threat presented by quantum computers is inadequate and will remain to be inadequate - all assuming such things are possible. Banks certainly should adopt quantum safe algorithms, but they haven't even got past 3DES yet.
I probably disagree that there are benefits to quantum computers if they exist, at least of a type that counterweights the dis-benefits of breaking a lot of in-the-field crypto. There are some optimization problems you could do better on, but who cares? Things will remain a little less optimal maybe.
On the fourth point, I'm not so sure. Nobody actually knows. Moore's law scaling is about semiconductor manufacture. Hard disks don't follow Moore's law. Lawnmowers don't follow Moore's law. You can fit 5 or 6 data points to an exponential curve getting from 1 qbit to 6, but will it continue? I don't see why it will.
Slashdot Mirror
I thought the most important thing was to fund the wages of the next American football team manager.
Those the the reasons I like Ada, or rather Ada written in VHDL, what with VHDL being pretty much a superset. It's a superb modeling language. You can easily constrain all state to be what the thing being modeled. But it's a fugly language and only the hard nosed people building chips had the stomach to take it. Which is why we are here today. Pity the people trying to build test benches in Verilog and having to investing in expensive test languages after finding how useless it is. The irony is VHDL is a pretty sucky HDL full of verbosity and boilerplate when you just want to describe binary logic.
Pair programming sounds horrible and I'm glad I don't have someone staring at my screen while I'm trying to slack off and read Slashdot.
"Right now we're just beta testing the St. Louis area, and we're getting positive hits," he says (meaning ads that match hotel-room photos in the database).
"Hits" or "False Positives" as they are known in statistics.
ADA is used by anyone that likes to have a long list of provable things about the code, like that a function never fails.
If you can prove that for any algorithm written in Ada, you've got a Fields medal in your future.
We get a current employee list from HR quarterly, and all employee changes immediately. Any account, including service accounts, that don't have a clear owner and purpose are disabled. There's no way an invalid user should have been in place for years.
Columbia make overpriced clothing, not overpriced software. Maybe they aren't so focused on IT security.
I don't know anyone using Ada but Ada begat VHDL. Lots of people use VHDL, but I doubt many people post their VHDL on github.
>I've found that most applicants suck.
That isn't because most applicants suck. That is because sucky applicants apply for a lot more jobs and interview many more times. Non sucky engineers tend to interview a lot less. So when you're on the interviewer, you see more sucky candidates.
If you want to see a higher quality of engineer walk in the door, offer more money and a nice work place with reasonable levels of autonomy.
It is unreasonable to expect mechanical engineer to be able to diagnose network issues, just like it would be unreasonable to expect network engineer to know how to calculate shear forces going through a support beam.
Funny you mention the latter. I would worry about you if you were unable to calculate sheer forces going through a beam. This stuff is high level enough that it is nothing more than typing numbers into a prepared excel spreadsheet.
Now whether you know the answer or not is entirely different. I would most definitely expect a mechanical engineer to be able to diagnose network issues. I don't expect them to be able to perfectly design it from the ground up or optimise the loading network wide but there is a very large scope of IT that we should expect people in general to be able to do.
My first paid job 30+ years ago was to port a mechanical engineer's basic code from a Sinclair QL to the Apple ][ called "Columns to BS449". So I'm pretty good with columns, not so much with beams.
All the companies I have been in that were small enough to not have dedicated IT specialists were awesome workplaces. They also didn't have password rules or office rules or messed up firewall proxies or the massive weight of corporate bureaucracy. You got to operate the coffee machine yourself rather than being at the mercy of an underpaid contract worker trained in food safety.
This.
I used to work with a 60+ year old analog electronics engineer. He neither knew nor cared anything networks or modern ways of working but with pen, paper and a lab he would build up a SMPS for whatever the current product was and then refine the shit out of it until it was quiet, reliable, efficient and small. He had a side business selling interesting audio electronics products.
You don't dismiss that wealth of experience and talent because they don't care about netmasks and gateways. You hire it and retain it. If anyone had a problem, we helped each other out.
So that's why I'm wealthy. I still have my Apple //e. I upgraded recently from a ][+
I've travelling this week and the place I'm staying only has OTA TV. We tried turning it on. It's a wasteland.
Yes. I wasn't saying it's not useful or interesting. I'm saying the benefits of speeding it up a bit are tiny compared to the costs of a quantum computer.
The comment is new. The state of affairs isn't.
The first is always free
1% is a pretty serious flaw. If it was my product I would be concerned as to whether or not it was a progressive failure and they're all going to fail in the end.
Allow me to correct myself:
"Just about any other product is less annoying than Google Hangouts."
Except maybe the NIST CSRC Statistical Test Suite: http://csrc.nist.gov/groups/ST...
I think that is the most annoying software.
So google developed webex? What am I missing here?
Skype for Business too.
Never heard the phrase "run it up the flagpole" but if you find the question "how will this scale?" annoying, you may want to choose a new line of business.
Indeed. It's a primary question you need to answer when proposing any new technology or solution.
If you ask me how my stuff scales, I'll give you the area/power/performance tradeoffs that are available in the design parameterization.
I did indeed look it up.
The first three hits are to the chemistry definition. The first is this.. "MSM METHYLSULFONYLMETHANE: Uses, Side Effects, Interactions"
That article supports my assertion that there aren't many compelling quantum algorithms unless you are trying to break crypto.
Lattice crypto mentioned in the article is not a quantum algorithm. It's a class of classical algorithms, some of which claim to be secure against quantum computers. They are also demonstrably hard to get right so they are secure against normal computers.
The paper it references "Exponential Lower Bounds for Polytopes in Combinatorial Optimization" is about optimization problems, which is exactly one of the boring things that the DWave machine does less efficiently than classical computers and if it were a solved problem it would at best find some slightly more optimal solutions to things like the traveling salesman problem, which might shave a few minutes of your next flight, but not nearly as much as plane companies building better planes would.
I've yet to see a compelling application beyond breaking crypto or showing that quantum computers can work - which is a little circular.
Wikipedia gives a convenient list. https://en.wikipedia.org/wiki/... - Read 'black box problem' as 'breaking crypto'.
There's nothing particularly compelling. Quantum computers make great science and great science yields benefits. If it does, I'm skeptical that it will be because they could solve a BQP problem efficiently.
My real problem is with the breathless tone of the article that perpetuates misconceptions.
(1 & 2) Yes. This is a nit I have with people who describe quantum interactions as reversible, because you can run the equations for the wave equations backwards. You can, as long as you ignore every other bit of energy in the universe but everything we know tells us you can't ignore thermodynamics when it comes to causality. Things are not reversible. That we have failed to implement useful quantum computers one data point consistent with this view.
(3) I hadn't considered side channels on quantum computers (to be fair as a result of my job, I've considered entangled adversary secure entropy extractors, which is similar but goes in the other direction) so thank you, something to think about.
I'm not sure in what way we disagree. My comments were all to do with the fashion in which people's response to the cryptographic threat presented by quantum computers is inadequate and will remain to be inadequate - all assuming such things are possible. Banks certainly should adopt quantum safe algorithms, but they haven't even got past 3DES yet.
I probably disagree that there are benefits to quantum computers if they exist, at least of a type that counterweights the dis-benefits of breaking a lot of in-the-field crypto. There are some optimization problems you could do better on, but who cares? Things will remain a little less optimal maybe.
On the fourth point, I'm not so sure. Nobody actually knows. Moore's law scaling is about semiconductor manufacture. Hard disks don't follow Moore's law. Lawnmowers don't follow Moore's law. You can fit 5 or 6 data points to an exponential curve getting from 1 qbit to 6, but will it continue? I don't see why it will.
Codecs can be implemented both in hardware and software.
Codecs for high quality compressed speech codes can be computationally intensive and so may be better done in hardware.