The trend to cloudify everything is still strong, but I've worked in the field long enough to say I'm confident it's going to trend back the other direction in the next decade or so. If you just look at the ridiculous number of data breaches in the news in the last year or two, you quickly see the problems with concentrating a large number of customer's data in one place. But hacking aside, the cloud services amount to giving up direct control over big chunks of your business operations. When one of these services has an outage, you can't do anything but sit around and hope they actually provide some status updates to pass along to your users and to management. Everyone's first question is "When will it be back up?" and you're stuck shrugging and saying, "Beats me! We're at the mercy of the provider." When this happens enough times, companies start demanding some more accountability and control.
I would stand up and cheer if that happened, and I used to believe that it would. Then I realized that it's no longer about quality. It's no longer about accountability. It's about whether they can sell the company to Google, Apple, or some investment firm for zillions of dollars in two years.
When you're planning for two years and not ten, a single outage (or even a month's worth) just isn't worth worrying about. It's about the spot revenues, not the long-term bottom line.
I do hope I'm wrong, and businesses finally wise up and start building actual long-term businesses instead of shiny crap-filled shells, but I'm not holding my breath.
The only cost would be in software. Those sensors already exist regardless, and the head unit is almost always already connected to the CAN bus, so it can talk to them.
I'm having a hard time believing that story. I would think that an employer demanding your ballot in any form (unfilled or otherwise) would be highly illegal.
...that would see a flood of students in the "Programming" courses, because suddenly there's a major that results in lucrative jobs that doesn't require math classes.
Since when was having a government-granted monopoly not a great business model?
Besides, that's like saying you're okay with extortion, because that's effectively what such a fee would be. "Give me fifty bucks, or I'll give your personal data to SolarCity and they'll harass you."
That data is MINE. If nothing else, it's incredibly disrespectful for any company to sell it on without my consent. It's just sad that this is the norm these days.
That was a much better argument before 60-inch TV's became commonplace. It's not a movie screen, but the difference is much less noticeable than when you were stuck watching it on a tiny 19".
This isn't about native code vs. VM-based runtimes. The advantage of C at the low level is that "what you see is what you get". There are certain overheads (like function call setup), but those overheads are predictable and well understood. The language inserts nothing that is not inherent in what you asked it to do. This is vitally important when dealing with low level hardware.
The vast majority of the "safety feature" implementations that I've seen in various languages necessarily add code that is executed at run-time. They might not have a run-time environment, or a library, but what you see is not what you get. Instead, it's up to the compiler to do what it will. You might write "a[3] = 42;", and get back two instructions -- one to check bounds, and one to actually perform the assignment -- instead of the one instruction you actually wanted. And then there will be code that handles the failure condition. That can wreck absolute havoc -- or it might completely and catastrophically disrupt what you're trying to do because it accesses something that shouldn't be accessed.
In the embedded world, it's also not uncommon for developers to write a set of instructions in a certain order because they know the exact number of cycles in which those instructions will run, and that is critical to hardware timing. That's less true for OS design on a modern desktop or server processor, but it still matters. C is perfect for this, because it doesn't emit magic that messes with your assumptions.
C maps very closely to assembly. There's a lot of embedded stuff out there that's written in assembly because even C isn't close enough to the hardware. Last time I looked (which was admittedly years ago), even Linux has assembly code in it, mostly in the boot process and the lowest levels of task handling and the system call interface. This is not because someone thought writing part of the kernel in assembly would be cool; in point of fact, they actively minimize it. It's because it's absolutely necessary when writing an operating system in order to meet various constraints posed by hardware.
High-level languages (even C) simply can't accomplish these things. C is the happy medium allowing all but the very lowest levels to be written in a language that doesn't get classified as "write once, read never."
...to keep them out of your network in the first place?
The shifting addresses could only apply to internal systems. Externally available systems (like, say, web servers) have to have known addresses for access, or you've defeated the entire purpose of having them externally accessible.
Which leads us back to firewalls and IDS and such.
I always think of guitars when people bring this up.
Walk into a guitar store and observe for a while. You'll see a lot of people pick up that $50 monstrosity that sounds like crap. It sounds like crap for all of them. Some of them pick up the $3000 guitar and it sounds okay, so they take it home.
Then the guy who actually knows how to play walks in, picks up that $50 guitar and makes it sound amazing -- and far better than anything you previously heard out of the $3000 models.
Moral of the story: the tool can't solve everything.
In the application space, you can argue all you want for better languages. There's nothing stopping it there. I'll still disagree with you, but there is no technical reason why the average application can't be written in whatever language you choose. Why? Because the low-level stuff is already done, far beneath your application.
If you're dealing with hardware (eg. writing an operating system, or code for a microcontroller that manages the brakes in your car), then using those higher level languages is a non-start. Every CPU cycle counts, especially in the latter case. Hardware does not understand the high level string constructs (not even C-style NULL terminated ones!) and data structures present in ANY high-level language. Hardware is a collection of registers in specific places that you have to poke and prod in specific orders to make things happen.
Good luck enforcing a safe memory access when that access involves poking raw numbers into sixteen different registers (some bit-level options, some addresses), and then going off to do something else while the DMA hardware (hopefully) executes it the way you intended. At the low level, you're going to be dealing with bounds-unchecked pointers whether you like it or not.
There is none of this safety you want in hardware.
Unless and until someone invents hardware that directly handles "managed code", languages like C are *very* necessary. They are the bridge between the hardware and whatever hipster silver-bullet language you've chosen to solve all your problems today.
The hipsters are the ones braying about NoSQL and the like. The senior engineers are the ones saying, "Yeah, we called those object databases back in the day. Seen it before. It won't solve your problem."
Everything (including so-called NoSQL) has its place. The senior people are the ones who know where that place is, and that nothing is a silver bullet.
OTOH, managers that don't understand how long software should take to build simply aren't qualified to be software development managers. The over-promising is often a symptom of this; people are afraid for their jobs if they tell the truth.
I've seen this far too many times to count. If managers truly understood the technology they were managing, we'd be far better off.
Just so all parties know the risks involved, it's all good.
Yeah, that's the problem. Once IT owns it, they're also the ones that take the blame when it fails; known risk factors don't make a bit of difference to the scapegoat when data is lost.
Therefore the scapegoat buys the most reliable storage it can afford.
as opposed to a zero chance of survival from the idiot swiping you from behind because you cannot SEE him at all, and have NO chance of evasive maneuvers
Repeating this fallacy doesn't make it any more valid than it was the first time.
Fact: you're riding on a road designed for cars. If you can't handle that, then don't do it.
Fact: all vehicles on that road (motorized or otherwise) are responsible for their own ability to drive safely and within the law. If you can't handle doing what every other driver and rider expects of you, then you have no business being on that road.
Fact: riding against traffic on a bicycle is no less stupid than riding against traffic on a motorcycle. There's no difference whatsoever. Well, except that the motorcycle is generally easier to see.
If you're having visibility problems, then you must be too cool for a rear-view mirror. They're five bucks at the local bike shop and solve that problem quite nicely. "Can't see the people behind me" isn't a valid excuse for endangering not only yourself, but everyone else on the road by doing something completely and idiotically unexpected, like driving head-on into traffic.
In short, you're the kind of guy that routinely fucks up my morning commute due to (a) an overinflated sense of entitlement to the use of a road intended for motorized vehicles, and (b) a complete and utter lack of common sense and self-preservation skills.
Oddly, I run a number of VMs that only have 128MB RAM and run just fine. They're complete Linux installs running web servers, NFS servers, custom apps, and more.
Oh wait, you meant JVMs...
Yeah, I think I'll not bother with Eclipse, thanks.
Slashdot Mirror
The trend to cloudify everything is still strong, but I've worked in the field long enough to say I'm confident it's going to trend back the other direction in the next decade or so. If you just look at the ridiculous number of data breaches in the news in the last year or two, you quickly see the problems with concentrating a large number of customer's data in one place. But hacking aside, the cloud services amount to giving up direct control over big chunks of your business operations. When one of these services has an outage, you can't do anything but sit around and hope they actually provide some status updates to pass along to your users and to management. Everyone's first question is "When will it be back up?" and you're stuck shrugging and saying, "Beats me! We're at the mercy of the provider." When this happens enough times, companies start demanding some more accountability and control.
I would stand up and cheer if that happened, and I used to believe that it would. Then I realized that it's no longer about quality. It's no longer about accountability. It's about whether they can sell the company to Google, Apple, or some investment firm for zillions of dollars in two years.
When you're planning for two years and not ten, a single outage (or even a month's worth) just isn't worth worrying about. It's about the spot revenues, not the long-term bottom line.
I do hope I'm wrong, and businesses finally wise up and start building actual long-term businesses instead of shiny crap-filled shells, but I'm not holding my breath.
(And yes, I'm generalizing.)
Wow. Blast from the past. I'd forgotten about those. :)
The only cost would be in software. Those sensors already exist regardless, and the head unit is almost always already connected to the CAN bus, so it can talk to them.
Or, you know, a database table that says what ballot ID number was mailed to which voter...
I'm having a hard time believing that story. I would think that an employer demanding your ballot in any form (unfilled or otherwise) would be highly illegal.
Bullets cost more. College is a profit center. :)
Hard plastic?
...that would see a flood of students in the "Programming" courses, because suddenly there's a major that results in lucrative jobs that doesn't require math classes.
We better do it. It'll solve the H1B problem.
Since when was having a government-granted monopoly not a great business model?
Besides, that's like saying you're okay with extortion, because that's effectively what such a fee would be. "Give me fifty bucks, or I'll give your personal data to SolarCity and they'll harass you."
That data is MINE. If nothing else, it's incredibly disrespectful for any company to sell it on without my consent. It's just sad that this is the norm these days.
Whoosh.
That was a much better argument before 60-inch TV's became commonplace. It's not a movie screen, but the difference is much less noticeable than when you were stuck watching it on a tiny 19".
Hardline copper is more resistant to outside interference.
Hardline copper is not used as a broadcast medium, so you're not sharing bandwidth with everyone in the neighborhood.
I'd hardly say that there's nothing inherently better about copper.
This isn't about native code vs. VM-based runtimes. The advantage of C at the low level is that "what you see is what you get". There are certain overheads (like function call setup), but those overheads are predictable and well understood. The language inserts nothing that is not inherent in what you asked it to do. This is vitally important when dealing with low level hardware.
The vast majority of the "safety feature" implementations that I've seen in various languages necessarily add code that is executed at run-time. They might not have a run-time environment, or a library, but what you see is not what you get. Instead, it's up to the compiler to do what it will. You might write "a[3] = 42;", and get back two instructions -- one to check bounds, and one to actually perform the assignment -- instead of the one instruction you actually wanted. And then there will be code that handles the failure condition. That can wreck absolute havoc -- or it might completely and catastrophically disrupt what you're trying to do because it accesses something that shouldn't be accessed.
In the embedded world, it's also not uncommon for developers to write a set of instructions in a certain order because they know the exact number of cycles in which those instructions will run, and that is critical to hardware timing. That's less true for OS design on a modern desktop or server processor, but it still matters. C is perfect for this, because it doesn't emit magic that messes with your assumptions.
C maps very closely to assembly. There's a lot of embedded stuff out there that's written in assembly because even C isn't close enough to the hardware. Last time I looked (which was admittedly years ago), even Linux has assembly code in it, mostly in the boot process and the lowest levels of task handling and the system call interface. This is not because someone thought writing part of the kernel in assembly would be cool; in point of fact, they actively minimize it. It's because it's absolutely necessary when writing an operating system in order to meet various constraints posed by hardware.
High-level languages (even C) simply can't accomplish these things. C is the happy medium allowing all but the very lowest levels to be written in a language that doesn't get classified as "write once, read never."
...to keep them out of your network in the first place?
The shifting addresses could only apply to internal systems. Externally available systems (like, say, web servers) have to have known addresses for access, or you've defeated the entire purpose of having them externally accessible.
Which leads us back to firewalls and IDS and such.
I always think of guitars when people bring this up.
Walk into a guitar store and observe for a while. You'll see a lot of people pick up that $50 monstrosity that sounds like crap. It sounds like crap for all of them. Some of them pick up the $3000 guitar and it sounds okay, so they take it home.
Then the guy who actually knows how to play walks in, picks up that $50 guitar and makes it sound amazing -- and far better than anything you previously heard out of the $3000 models.
Moral of the story: the tool can't solve everything.
In the application space, you can argue all you want for better languages. There's nothing stopping it there. I'll still disagree with you, but there is no technical reason why the average application can't be written in whatever language you choose. Why? Because the low-level stuff is already done, far beneath your application.
If you're dealing with hardware (eg. writing an operating system, or code for a microcontroller that manages the brakes in your car), then using those higher level languages is a non-start. Every CPU cycle counts, especially in the latter case. Hardware does not understand the high level string constructs (not even C-style NULL terminated ones!) and data structures present in ANY high-level language. Hardware is a collection of registers in specific places that you have to poke and prod in specific orders to make things happen.
Good luck enforcing a safe memory access when that access involves poking raw numbers into sixteen different registers (some bit-level options, some addresses), and then going off to do something else while the DMA hardware (hopefully) executes it the way you intended. At the low level, you're going to be dealing with bounds-unchecked pointers whether you like it or not.
There is none of this safety you want in hardware.
Unless and until someone invents hardware that directly handles "managed code", languages like C are *very* necessary. They are the bridge between the hardware and whatever hipster silver-bullet language you've chosen to solve all your problems today.
Don't mistake "hipster" for "senior."
The hipsters are the ones braying about NoSQL and the like. The senior engineers are the ones saying, "Yeah, we called those object databases back in the day. Seen it before. It won't solve your problem."
Everything (including so-called NoSQL) has its place. The senior people are the ones who know where that place is, and that nothing is a silver bullet.
OTOH, managers that don't understand how long software should take to build simply aren't qualified to be software development managers. The over-promising is often a symptom of this; people are afraid for their jobs if they tell the truth.
I've seen this far too many times to count. If managers truly understood the technology they were managing, we'd be far better off.
Google Army.
Hey! That dollar would feed a dozen starving children!
Just so all parties know the risks involved, it's all good.
Yeah, that's the problem. Once IT owns it, they're also the ones that take the blame when it fails; known risk factors don't make a bit of difference to the scapegoat when data is lost.
Therefore the scapegoat buys the most reliable storage it can afford.
as opposed to a zero chance of survival from the idiot swiping you from behind because you cannot SEE him at all, and have NO chance of evasive maneuvers
Repeating this fallacy doesn't make it any more valid than it was the first time.
Fact: you're riding on a road designed for cars. If you can't handle that, then don't do it.
Fact: all vehicles on that road (motorized or otherwise) are responsible for their own ability to drive safely and within the law. If you can't handle doing what every other driver and rider expects of you, then you have no business being on that road.
Fact: riding against traffic on a bicycle is no less stupid than riding against traffic on a motorcycle. There's no difference whatsoever. Well, except that the motorcycle is generally easier to see.
If you're having visibility problems, then you must be too cool for a rear-view mirror. They're five bucks at the local bike shop and solve that problem quite nicely. "Can't see the people behind me" isn't a valid excuse for endangering not only yourself, but everyone else on the road by doing something completely and idiotically unexpected, like driving head-on into traffic.
In short, you're the kind of guy that routinely fucks up my morning commute due to (a) an overinflated sense of entitlement to the use of a road intended for motorized vehicles, and (b) a complete and utter lack of common sense and self-preservation skills.
Oddly, I run a number of VMs that only have 128MB RAM and run just fine. They're complete Linux installs running web servers, NFS servers, custom apps, and more.
Oh wait, you meant JVMs...
Yeah, I think I'll not bother with Eclipse, thanks.
Been there, done that, believe it was patented by iPIX. Not sure who holds it now since they're gone AFAIK...
Seriously, they used this to do those 3D virtual tours.
Not to take sides in this particular debate, but... ...tell that to Enron.
--S