A somewhat nightmare scenario is that they just add initial (and possibly even broken) support for it that is feature incomplete, and as a result, you start seeing new SSH clients come around that are broken and/or only work with the Microsoft implementation. In other words, kind of like what Microsoft did to ruin HTML4.
Wut? Ruin HTML4? HTML 5 is largely HTML4 + DHTML. Microsoft added features that developers wanted. It took from 1997 when Microsoft released DHTML until 2014 when the w3c formalized HTML5 for an official "Standard" to decide that Microsoft's approach was wrong.
Between 1994 when HTML4 was ratified and 20 years later when HTML5 was ratified essentially everything was equally standards non-compliant. Microsoft, Apple and Netscape were all adding extensions and moving exponentially faster than the w3c. The lack of standards compliance is an indictment of w3c's ability to keep up with the fast moving pace needed for innovation to take place. We're seeing the same thing again with webkit adding extensions that developers want. But since the w3c is so slow to offer standards the webkit extensions are simply going to be the defacto standard. Hopefully we'll see HTML6 before 2035 and not bemoan in 5 years how horribly non-standards compliant webkit has become as browser developers refuse to restrict themselves to the W3C's glacial pace.
Rule #1 of crypto: don't write your own Rule #2 of crypto: DON'T write your own Rule #3 of crypto: DON'T WRITE YOUR OWN
They're not difficult rules to follow. But then they
Rules #1, #2 and #3 only apply to your average Joe developer. Microsoft's cryptography libraries predate OpenSSL and they serve as the foundation of dozens of Microsoft products including Windows Server etc.
I remember OpenSSL having a giant security breach this year. I don't remember Microsoft's internal API suffering from a similar failure. The NSA is as likely and as capable of slipping a back door into OpenSSL as they are into Microsoft's internal code base. And as evidenced by Heartbleed, even with lots of eyes, we aren't confident that it will be noticed.
Bullshit. Clearly some improvement happens going from single to multithreaded, but I suspect very few desktops have >4 cores, and a vanishingly small number >16.
Well, for one, it's 36 threads, which means 18 cores. Two, the types of computers which this is useful for (multi-processor renderfarms, virtualized guest OSes and compute clusters) you do often have 40+ threads.
If you want to play Doom 4, go buy a GPU, llvmpipe isn't useful for you either. So there was a solution for a specific group of people who had one solution (llvmpipe) and now those same people now have a much faster solution.
This is like an announcement that MRI machines have been made 100% more energy efficient and you whining that it only applies to hospitals and not your home refrigerator. No shit.
1) Virtualization which often doesn't support GPU sharing. I would love this on HyperV guests. 2) Remote Desktop scenarios where the GPU won't load. 3) Servers with no on-board GPU at all but rely on OpenGL for specific UI elements.
There's a huge difference between "Ads" aka anyone who wants to market to you and "Hey, you might want to check out this popular app that's *free."
It's in the app section, it features apps you can use. That's barely an ad. And it's a far cry from gathering personal information about you so that Google can target that Viagra commercial at you.
Next people are going to be bitching that Windows Maps uses your GPS data when you're following turn by turn directions.
The author doesn't caveat his opinion as "Autonomous cars aren't good enough *yet*." He simply states that history tells us that we will *never* have autonomous vehicles. He's apparently writing a book about Apollo Era rockets. I guess he's so far behind the times that he doesn't realize that computer science has advanced beyond what he clearly thinks is possible. His argument is essentially "Autonomous vehicles have always needed pilots, therefore autonomous vehicles will always need pilots."
When in doubt. Slow as quickly as possible. If you have a safe following distance (which you always should have) then unless a problem emerges somehow out of thin air the worst that will happen is that you can't proceed. But you should always understand the condition of the road ahead of you or stop before you reach it. That's true of autonomy and true of real human drivers. You drive only as fast as you can see. If you can't see around a bend, drive slow enough that you can stop should something be stopped around the corner. If you can't see far enough to complete the pass, don't pass.
If a autonomous car encounters something it doesn't understand, it can simply come to a stop because it should have entered its FOV beyond its stopping distance. Then you can (wake up) and give it the go-ahead or not.
Because reasons. Seriously this should be emberassing for MIT to come from one of their own.
"If robotics in extreme environments are any guide, Mindell says, self-driving cars should not be fully self-driving. That idea, he notes, is belied by decades of examples involving spacecraft, underwater exploration, air travel, and more. In each of those spheres, fully automated vehicles have frequently been promised, yet the most state-of-the-art products still have a driver or pilot somewhere in the network. "
Let's break down the reasons why this is an idiotic statement.
1) "If robotics in extreme environments are any guide." Why would extreme environments be a guide to how people commute. Previous Robotics were all about going to extremely hazardous environments where people couldn't live to learn things about places we know little to nothing about. Compare that to our transit system which by definition someone knows so well that they built a road there and the caveat makes no sense.
2) "That idea is belied by decades of examples" So because older inferior computers and analog systems were limiting we'll be limited for all time? Sorry but no. That's like saying "Because the horse and carriage have always traveled at 30mph or less, no good will come from traveling at speeds in excess of 100mph."
His entire argument comes down to fully autonomous cars (taxis) are bad because space exploration requires human direction and Apollo era hardware/software wasn't sufficiently capable of handling 100% of a mission.
I don't think the price is the problem. Anyone who has lived in an Apartment building with a shared washing machine and dryer knows the hassle of someone (often admittedly me too) who puts in a load of wash then forgets to move it.
If you poach the spot and slip in line then they might feel like someone snuck in if they had multiple loads. You don't know if it just barely finished or has sat there for hours.
Not that VMWare is bad, it is a good product, it is just really expensive, to the point where you can consider getting additional low end servers vs virtualizing them.
Oh, it's definitely *cheaper* to virtualize multiple low-end servers. But you don't get live-migration. You can't back up the image and migrate it to a similar but different machine. You can't spin up additional instances on a moment's notice. You can't build a megabox where sometimes a single virtual machine takes up 64GB of RAM and other times is a small 2GB fly on the wall. You lose performance with virtualization (In my testing about 10-15%) but you gain a lot of ease of maintenance.
We have a render farm and I just deployed a fresh image to half of them yesterday with a single powershell script. It takes less time than some windows updates. It takes a lot less time than installing a suite of applications and tooling them to run correctly on each machine.
These reservation systems are actually technological marvels and a bit of a miracle that they work at all. They often not only track purchases, but they also have to dynamically self-correct for delays. If a plane full of people in Houston are delayed 3 hours then it has to begin a system wide dependency calculation to find them all seats on later flights. I can see just at a glance how that would be a nightmare to distribute and scale easily. You can't have a race condition where two delayed flights try to put all of their passengers who will miss connections onto the same flight. And then you get into the calculation "do you delay another flight so that delayed connecting passengers can make their connection but then cause passengers on the that flight to miss their next connection... which is worse?" etc.
If Adobe rewrites their CC apps for WinRT from Win32 they would semi-automatically pick up ARM support. But now that Microsoft is offering Win32 through the Windows Store they'll probably never move over to WinRT except on their mobile apps. Microsoft *should* have thrown $100m at Adobe and said "get this Win32 ARM compiler that we used to create Microsoft Office and port Photoshop" at the launch of Surface RT. That would have been an enormous coup.
It's rumored the Surface Phone will be x86 and run Win32 apps when in Desktop mode. At that point, Windows's experiment with ARM will be entirely limited to budget phones and then probably nothing again.
In the past companies have reversed their decision based on public outcry; it's not unprecedented.
My guess is that Verizon loses money on the handful of grandfathered plans that remain. You can stomp your feet and pout but it's like the old "sure we're losing money on each item but we'll make up for it on volume."
Getting people to quit is the *point* of this move. They want people to quit so that they stop wasting their attention and resources on a handful of entitled customers that they no longer want.
If I had a manger in a software development team role, I'd want a structure where I'd look to him as my peer; there to do an important job of his own, where we evaluate each other; and where we can replace him if he's not working out...
This is how our company works and it's perfect. Their role is to handle client interaction, to set budgets (and hold us to budgets) as well as set schedules and work with us to accomplish the schedule. Ultimately their ass is on the line for staying within budget and schedule so anything within the purview of budget and schedule they are god. If something has to be cut because of budget, we cut it. So that naturally creates a healthy working dynamic. If they need to cut the schedule and/or budget then they come to an artist and ask them if we have any proposals. They then handle working with the client to let the client understand what the implications of moving up a deadline.
But just like an executive assistant isn't actually superior to an executive a producer or project manager isn't actually superior to the team they just are responsible for different aspects of the team's performance. And we understand that it's their ass on the line for schedule so if we deliver late, we need to let them know. If someone isn't delivering on time and making the producer look bad then we aren't going to team up on the project manager or producer like you would if they were your superior you are all in it together and if you are happy with your project manager's work then you can usually all pretty easily recognize the real problem source: the team member who isn't delivering on time. Conversely if the producer is setting impossible deadlines and not providing support to achieve those deadlines then everybody on the team will pretty easily be able to identify the source of the problem. It's not a position that is more highly paid, it's just another position on the team. You need goalies and you need forwards and you need coaches. Sometimes coaches get paid more, sometimes goalies get paid more, sometimes strikers get paid more. You need a chain of command, but mostly just to make arbitrary decisions.
The problem is regarding management as a position of importance that people are promoted to.
This is perhaps one of the single largest failures of our social organization. "Boss" has come to mean "important" or "ruler" instead of being an integral component to facilitate real work. It would be like saying that a switch is the most important and valuable piece of hardware in an organization.
In college I studied film direction and my friend was studying producing and one night while bitching about this exact phenomenon (everyone wanting to be a director or producer because "they're in charge" instead of because they were attracted to the unique specialized work of a director or producer) we settled on the "Doer and Enabler" dichotomy. Directors, Managers, Producers, Supervisors are not Doers, they are Enablers. An enabler's job is to help the doers do. An enabler should be clearing the way, organizing materials and answering questions that doers need answered. A doer obviously actually creates things and does the work.
There certainly are Doer/Enablers, if you have an art director, or a software architect they often start to straddle enabling others to execute their vision while also providing a high level plan--but for the most part management is not a doer, they are an enabler.
However, people generally want more money than they have so the only way to get that more-money is to become a manager. It's stupid. If I was running an experiment I wouldn't fire all of my enablers, I would simply stop making the management position necessarily an upgrade or promotion but more of a crossgrade with a similar payscale.
If it worked as intended it would have been a good deal.
$65m in "stolen" money as you call it (taxes).
$250k tickets * say 10,000 = $2,500,000,000 into the net economy. Let's say that 15% of that is operations that's still $375m back into the economy in the form of wages. You aren't going to find a 576% investment opportunity very often.
Furthermore those people would probably want to eat somewhere while in town and maybe even visit a shop or two which would further boost the local economy.
It was a sound plan, and I'm sure virgin would very much like to be making a ton of money as well but the part that failed was the fact that they didn't have more protections for the county in the event that say.. a rocket exploded and the business plan was put on hold for 10 years.
None of the geeks I know watch TV. They are too busy getting stuff done.
You don't know any geeks who watch Game of Thrones or The Walking Dead or...
I like the Big Bang Theory. It's not smart, it doesn't try to be smart but I find it plenty funny. Sure they laugh at the geeks, but they also laugh at the non-geeks. Geeks are getting pissed off because geeks are being made fun of but it's like South Park, there is nobody who is off limits so it's fine. The geeks are dumb and the regular people are neanderthals. Bafoonery is a old reliable source of comedy.
How long must either car wait before embarking on a trip? Say, because there is an emergency situation?
If it's an emergency use an Uber. Emergency means you spend money on a cab/airplane ticket/911 Ambulence.
How long must either car wait before embarking on a trip?
If you have a garage you don't have to factor stopping for gas on the way out of town. I often have to stop and refuel before leaving on a road trip. With an electric car I could just plugin the night before and be ready to leave without a detour.
That "convenience factor" of hydrocarbon fuels is a real thing, and it's a real value.
There is nothing more convenient than fueling up in your own home inside of a garage out of the wind and rain.
Slashdot Mirror
A somewhat nightmare scenario is that they just add initial (and possibly even broken) support for it that is feature incomplete, and as a result, you start seeing new SSH clients come around that are broken and/or only work with the Microsoft implementation. In other words, kind of like what Microsoft did to ruin HTML4.
Wut? Ruin HTML4? HTML 5 is largely HTML4 + DHTML. Microsoft added features that developers wanted. It took from 1997 when Microsoft released DHTML until 2014 when the w3c formalized HTML5 for an official "Standard" to decide that Microsoft's approach was wrong.
Between 1994 when HTML4 was ratified and 20 years later when HTML5 was ratified essentially everything was equally standards non-compliant. Microsoft, Apple and Netscape were all adding extensions and moving exponentially faster than the w3c. The lack of standards compliance is an indictment of w3c's ability to keep up with the fast moving pace needed for innovation to take place. We're seeing the same thing again with webkit adding extensions that developers want. But since the w3c is so slow to offer standards the webkit extensions are simply going to be the defacto standard. Hopefully we'll see HTML6 before 2035 and not bemoan in 5 years how horribly non-standards compliant webkit has become as browser developers refuse to restrict themselves to the W3C's glacial pace.
Rule #1 of crypto: don't write your own
Rule #2 of crypto: DON'T write your own
Rule #3 of crypto: DON'T WRITE YOUR OWN
They're not difficult rules to follow. But then they
Rules #1, #2 and #3 only apply to your average Joe developer. Microsoft's cryptography libraries predate OpenSSL and they serve as the foundation of dozens of Microsoft products including Windows Server etc.
I remember OpenSSL having a giant security breach this year. I don't remember Microsoft's internal API suffering from a similar failure. The NSA is as likely and as capable of slipping a back door into OpenSSL as they are into Microsoft's internal code base. And as evidenced by Heartbleed, even with lots of eyes, we aren't confident that it will be noticed.
Bullshit. Clearly some improvement happens going from single to multithreaded, but I suspect very few desktops have >4 cores, and a vanishingly small number >16.
Well, for one, it's 36 threads, which means 18 cores. Two, the types of computers which this is useful for (multi-processor renderfarms, virtualized guest OSes and compute clusters) you do often have 40+ threads.
If you want to play Doom 4, go buy a GPU, llvmpipe isn't useful for you either. So there was a solution for a specific group of people who had one solution (llvmpipe) and now those same people now have a much faster solution.
This is like an announcement that MRI machines have been made 100% more energy efficient and you whining that it only applies to hospitals and not your home refrigerator. No shit.
There are a lot of applications I can think of:
1) Virtualization which often doesn't support GPU sharing. I would love this on HyperV guests.
2) Remote Desktop scenarios where the GPU won't load.
3) Servers with no on-board GPU at all but rely on OpenGL for specific UI elements.
I mean, they're both TV spots showing people using the product in a variety of settings, what a rip off. They even both have a narration!
There's a huge difference between "Ads" aka anyone who wants to market to you and "Hey, you might want to check out this popular app that's *free."
It's in the app section, it features apps you can use. That's barely an ad. And it's a far cry from gathering personal information about you so that Google can target that Viagra commercial at you.
Next people are going to be bitching that Windows Maps uses your GPS data when you're following turn by turn directions.
The author doesn't caveat his opinion as "Autonomous cars aren't good enough *yet*." He simply states that history tells us that we will *never* have autonomous vehicles. He's apparently writing a book about Apollo Era rockets. I guess he's so far behind the times that he doesn't realize that computer science has advanced beyond what he clearly thinks is possible. His argument is essentially "Autonomous vehicles have always needed pilots, therefore autonomous vehicles will always need pilots."
When in doubt. Slow as quickly as possible. If you have a safe following distance (which you always should have) then unless a problem emerges somehow out of thin air the worst that will happen is that you can't proceed. But you should always understand the condition of the road ahead of you or stop before you reach it. That's true of autonomy and true of real human drivers. You drive only as fast as you can see. If you can't see around a bend, drive slow enough that you can stop should something be stopped around the corner. If you can't see far enough to complete the pass, don't pass.
If a autonomous car encounters something it doesn't understand, it can simply come to a stop because it should have entered its FOV beyond its stopping distance. Then you can (wake up) and give it the go-ahead or not.
Because reasons. Seriously this should be emberassing for MIT to come from one of their own.
"If robotics in extreme environments are any guide, Mindell says, self-driving cars should not be fully self-driving. That idea, he notes, is belied by decades of examples involving spacecraft, underwater exploration, air travel, and more. In each of those spheres, fully automated vehicles have frequently been promised, yet the most state-of-the-art products still have a driver or pilot somewhere in the network. "
Let's break down the reasons why this is an idiotic statement.
1) "If robotics in extreme environments are any guide." Why would extreme environments be a guide to how people commute. Previous Robotics were all about going to extremely hazardous environments where people couldn't live to learn things about places we know little to nothing about. Compare that to our transit system which by definition someone knows so well that they built a road there and the caveat makes no sense.
2) "That idea is belied by decades of examples" So because older inferior computers and analog systems were limiting we'll be limited for all time? Sorry but no. That's like saying "Because the horse and carriage have always traveled at 30mph or less, no good will come from traveling at speeds in excess of 100mph."
His entire argument comes down to fully autonomous cars (taxis) are bad because space exploration requires human direction and Apollo era hardware/software wasn't sufficiently capable of handling 100% of a mission.
Ugh... I meant to say "It's definitely *cheaper* to build multiple low end-servers *than* to virtualize."
I don't think the price is the problem. Anyone who has lived in an Apartment building with a shared washing machine and dryer knows the hassle of someone (often admittedly me too) who puts in a load of wash then forgets to move it.
If you poach the spot and slip in line then they might feel like someone snuck in if they had multiple loads. You don't know if it just barely finished or has sat there for hours.
Not that VMWare is bad, it is a good product, it is just really expensive, to the point where you can consider getting additional low end servers vs virtualizing them.
Oh, it's definitely *cheaper* to virtualize multiple low-end servers. But you don't get live-migration. You can't back up the image and migrate it to a similar but different machine. You can't spin up additional instances on a moment's notice. You can't build a megabox where sometimes a single virtual machine takes up 64GB of RAM and other times is a small 2GB fly on the wall. You lose performance with virtualization (In my testing about 10-15%) but you gain a lot of ease of maintenance.
We have a render farm and I just deployed a fresh image to half of them yesterday with a single powershell script. It takes less time than some windows updates. It takes a lot less time than installing a suite of applications and tooling them to run correctly on each machine.
These reservation systems are actually technological marvels and a bit of a miracle that they work at all. They often not only track purchases, but they also have to dynamically self-correct for delays. If a plane full of people in Houston are delayed 3 hours then it has to begin a system wide dependency calculation to find them all seats on later flights. I can see just at a glance how that would be a nightmare to distribute and scale easily. You can't have a race condition where two delayed flights try to put all of their passengers who will miss connections onto the same flight. And then you get into the calculation "do you delay another flight so that delayed connecting passengers can make their connection but then cause passengers on the that flight to miss their next connection... which is worse?" etc.
If Adobe rewrites their CC apps for WinRT from Win32 they would semi-automatically pick up ARM support. But now that Microsoft is offering Win32 through the Windows Store they'll probably never move over to WinRT except on their mobile apps. Microsoft *should* have thrown $100m at Adobe and said "get this Win32 ARM compiler that we used to create Microsoft Office and port Photoshop" at the launch of Surface RT. That would have been an enormous coup.
It's rumored the Surface Phone will be x86 and run Win32 apps when in Desktop mode. At that point, Windows's experiment with ARM will be entirely limited to budget phones and then probably nothing again.
In the past companies have reversed their decision based on public outcry; it's not unprecedented.
My guess is that Verizon loses money on the handful of grandfathered plans that remain. You can stomp your feet and pout but it's like the old "sure we're losing money on each item but we'll make up for it on volume."
Getting people to quit is the *point* of this move. They want people to quit so that they stop wasting their attention and resources on a handful of entitled customers that they no longer want.
If I had a manger in a software development team role, I'd want a structure where I'd look to him as my peer; there to do an important job of his own, where we evaluate each other; and where we can replace him if he's not working out...
This is how our company works and it's perfect. Their role is to handle client interaction, to set budgets (and hold us to budgets) as well as set schedules and work with us to accomplish the schedule. Ultimately their ass is on the line for staying within budget and schedule so anything within the purview of budget and schedule they are god. If something has to be cut because of budget, we cut it. So that naturally creates a healthy working dynamic. If they need to cut the schedule and/or budget then they come to an artist and ask them if we have any proposals. They then handle working with the client to let the client understand what the implications of moving up a deadline.
But just like an executive assistant isn't actually superior to an executive a producer or project manager isn't actually superior to the team they just are responsible for different aspects of the team's performance. And we understand that it's their ass on the line for schedule so if we deliver late, we need to let them know. If someone isn't delivering on time and making the producer look bad then we aren't going to team up on the project manager or producer like you would if they were your superior you are all in it together and if you are happy with your project manager's work then you can usually all pretty easily recognize the real problem source: the team member who isn't delivering on time. Conversely if the producer is setting impossible deadlines and not providing support to achieve those deadlines then everybody on the team will pretty easily be able to identify the source of the problem. It's not a position that is more highly paid, it's just another position on the team. You need goalies and you need forwards and you need coaches. Sometimes coaches get paid more, sometimes goalies get paid more, sometimes strikers get paid more. You need a chain of command, but mostly just to make arbitrary decisions.
The problem is regarding management as a position of importance that people are promoted to.
This is perhaps one of the single largest failures of our social organization. "Boss" has come to mean "important" or "ruler" instead of being an integral component to facilitate real work. It would be like saying that a switch is the most important and valuable piece of hardware in an organization.
In college I studied film direction and my friend was studying producing and one night while bitching about this exact phenomenon (everyone wanting to be a director or producer because "they're in charge" instead of because they were attracted to the unique specialized work of a director or producer) we settled on the "Doer and Enabler" dichotomy. Directors, Managers, Producers, Supervisors are not Doers, they are Enablers. An enabler's job is to help the doers do. An enabler should be clearing the way, organizing materials and answering questions that doers need answered. A doer obviously actually creates things and does the work.
There certainly are Doer/Enablers, if you have an art director, or a software architect they often start to straddle enabling others to execute their vision while also providing a high level plan--but for the most part management is not a doer, they are an enabler.
However, people generally want more money than they have so the only way to get that more-money is to become a manager. It's stupid. If I was running an experiment I wouldn't fire all of my enablers, I would simply stop making the management position necessarily an upgrade or promotion but more of a crossgrade with a similar payscale.
2) Its relatively close to the equator while in the US.
These are suborbital flights, so there is nothing to be gained from your latitude, you just go straight up and then straight back down.
If it worked as intended it would have been a good deal.
$65m in "stolen" money as you call it (taxes).
$250k tickets * say 10,000 = $2,500,000,000 into the net economy. Let's say that 15% of that is operations that's still $375m back into the economy in the form of wages. You aren't going to find a 576% investment opportunity very often.
Furthermore those people would probably want to eat somewhere while in town and maybe even visit a shop or two which would further boost the local economy.
It was a sound plan, and I'm sure virgin would very much like to be making a ton of money as well but the part that failed was the fact that they didn't have more protections for the county in the event that say.. a rocket exploded and the business plan was put on hold for 10 years.
None of the geeks I know watch TV.
They are too busy getting stuff done.
You don't know any geeks who watch Game of Thrones or The Walking Dead or...
I like the Big Bang Theory. It's not smart, it doesn't try to be smart but I find it plenty funny. Sure they laugh at the geeks, but they also laugh at the non-geeks. Geeks are getting pissed off because geeks are being made fun of but it's like South Park, there is nobody who is off limits so it's fine. The geeks are dumb and the regular people are neanderthals. Bafoonery is a old reliable source of comedy.
3) They also moved drivers into user space so those bluescreens you refer to rarely happen these days even with garbage drivers.
How long must either car wait before embarking on a trip? Say, because there is an emergency situation?
If it's an emergency use an Uber. Emergency means you spend money on a cab/airplane ticket/911 Ambulence.
How long must either car wait before embarking on a trip?
If you have a garage you don't have to factor stopping for gas on the way out of town. I often have to stop and refuel before leaving on a road trip. With an electric car I could just plugin the night before and be ready to leave without a detour.
That "convenience factor" of hydrocarbon fuels is a real thing, and it's a real value.
There is nothing more convenient than fueling up in your own home inside of a garage out of the wind and rain.
Or it's like speeding. Sure it's illegal. But it's also mighty convenient.
"Yes officer I was totally paying attention to the road and I was just squinting into the sun."
So do gas powered engines.
https://en.wikipedia.org/wiki/...
The solution is the same, use energy to maintain minimum temperature (which the Tesla does) at the cost of about 33% range.