As a matter of fact, it is.Blockchain would be a terrible idea for real estate. Understand the two key things about it and you'll understand why:
First, Blockchain is used when there is no suitable central authority to rely on. Each change to a protected asset is cryptographically authenticated by equipment run by multiple organizations. The consensus of those authentications accepts the change. When a central authority like a government agency is readily available, there is no need for this technique. Indeed it's more expensive than using a single trusted central authority.
Second, Blockchain is intentionally irreversible. Once a change is published and accepted, it can never be removed or undone. In financial transactions, that's actually a bad thing. Combating fraud in financial transactions (such as real estate transactions) critically depends on reversing false changes.
An asset protected by Blockchain can only be changed by someone who has the key for the most recent change. When your key is stolen and used to publish a false change, that's no longer you... it's the thief. When your key is lost on a crashed hard drive, nobody can publish further changes to the asset. Ever again.
Immutable containers require (1) exhaustive automated testing and (2) ongoing software development for the lifetime of the product, that is the product must be discontinued at the same time as active development.
The first is merely expensive. The second - disallowing the very concept of legacy apps - hasn't demonstrated that it can be sustained over time.
When DevOps is done well, it joins development and operations. If you have separate Development, System Administration and DevOps teams, you're doing it wrong so of course you fail.
On the other hand, too much modern devops has reinvented the wheel, improving upon practices which were obsolete 20 years ago. Puppet? Chef? Ansible? Hello rdist and rsh. Crappy then, crappy now. Docker? How the eff do you validate security compliance and successfully patch docker images? You know, the job that in normal VMs gets handled by "yum update." Docker is a security disaster area.
Before everything was connected on the Internet, there were code-generating platforms that let non-programmers assemble common cookie-cutter apps without needing any kind of software development skills. Hypercard, Powerbuilder, things like that. The original author bemoans the loss of these tools.
The problem is: modern software requires security. It must be resilient in the face of somebody actively trying to subvert it. You don't get that from a lego set. You need somebody who has some idea what they're doing.
This Plus. Not only was I underutilized, I was forced to work with a guy who was not just incompetent but willfully ignorant.
How ignorant, you ask? His program spawned 14,000 active threads because he kept starting up pools of http workers and fail to stop the old pools before starting up more. When confronted with his mistake he first insisted that the program was running out of memory (not spawning threads). Then he insisted that 14,000 simultaneous threads was completely reasonable. Then he claimed that it was the Java garbage collector's fault and he couldn't control when it would reclaim used threads (hint: the garbage collector doesn't reclaim threads. It reclaims memory when no threads still use it).
Basic income is better than a guaranteed job by a long shot. Working a worthless job is not only soul-crushing, it consumes the time you could have spent bettering yourself so that you can get a real job.
However, I disagree with the concept of a universal basic income. It is morally bankrupt to vote yourself ownership of other people's money. I would prefer to see an optional basic income where any adult citizen is guaranteed a fixed daily stipend, BUT no one who accepts the stipend may vote in federal elections for four years before and after receiving the money.
This would assure that only the folks funding the basic income get to choose how much they're willing to pay. It would give the basic income a fundamental fairness that a universal basic income lacks.
Incidentally, have you considered the numbers? There are somewhere around 250 million adult US citizens. Paying them each the poverty threshold income of just over $15,000 per year would cost just under 4 trillion dollars a year. It would be hugely expensive, around 20% of the GDP.
Maybe a decade ago, but if you're building a web app on hardware more constrained than the $10 Raspberry Pi Zero these days then you're probably doing it wrong.
Also, I don't know where you get the idea that Apache apr saves you from buffer overflows. You're still working with char*'s.
If you're building a web app in C, you're probably doing it wrong. C's runtime efficiency is unparalleled but its prone to buffer bounding mistakes and writing successful C code is slow. Your time as a software developer is generally more valuable than the servers which will run it and there are at least half a dozen mainstream languages that permit a convenient, fast job of the kinds of tasks typical of a web app.
Your claim is similar to saying that a hot dog is not cooked well because it's not an omelette.
If you put a hot dog on a bun and hand it to the customer without first grilling or microwaving or somehow warming it up, it's edible but it's not cooked well. More to the point, it is very unlikely to be what the customer desires.
It's equally obvious that the default for a USB-based filesystem should be that it's in a state ready to be disconnected unless a user space program is blocked writing to it right this moment.
If you want a USB raid for manipulating video files, you can set the drive to use non-default options.
The buffer is where the data sits while waiting for the receiver to finish receiving and accept it. The write() call can return immediately while the OS sends data from the buffer in the background. The write call can block until the OS finishes sending data from the buffer. Either way there's a buffer that holds the data being sent until the OS is done with it.
There aren't a lot of bad C developers. Bad developers can't get their C programs to work at all (let alone correctly), so they move on to another language.
Bad Java developers abound. Not because Java is a bad language, quite the contrary. But lousy developers can swallow exceptions and muddle along with code that more or less does what it's supposed to. Java protects them from the core dump.
If I break into a server and find everything compiled then all I have is some compiled binaries.
Unless you're writing in C (and if you're building a web app, you probably aren't) the object code tends to decompile into a pretty close copy of the original source minus the comments. If you thought Java meant you couldn't get back to the source code, think again.
If your operating system was programmed well, the IO call writing to the USB drive would not return until all write buffers were flushed, would not permit large write buffers to a USB drive -and- nothing else would attempt to write the USB drive in the background.
Your operating system was not programmed well. Quick Removal only gets close.
It's easy in linux to make the program directory unwritable by the program and the data directory unexecutable. Same for ram: easy to mark the program memory read-only and the data memory non-executable.
So how is this extraneous code successfully getting executed?
Generally speaking, if you gain continuous control of a previously unclaimed location, that location belongs to you. Planting a flag is not sufficient. Planting a person is, but only for the area over which that person is capable of exerting control.
Treaty or no treaty, the parts of the moon will go the same way.
Slashdot Mirror
"Now that I've made my final mortgage payment Mr. Bank, please sign the property over to my crypto ID."
"Sorry, the key we used for your property was lost in the Great Server Crash of '15."
Re-read what I wrote. I answered that question.
Blockchain for real-estate titles isn't stupid.
As a matter of fact, it is.Blockchain would be a terrible idea for real estate. Understand the two key things about it and you'll understand why:
First, Blockchain is used when there is no suitable central authority to rely on. Each change to a protected asset is cryptographically authenticated by equipment run by multiple organizations. The consensus of those authentications accepts the change. When a central authority like a government agency is readily available, there is no need for this technique. Indeed it's more expensive than using a single trusted central authority.
Second, Blockchain is intentionally irreversible. Once a change is published and accepted, it can never be removed or undone. In financial transactions, that's actually a bad thing. Combating fraud in financial transactions (such as real estate transactions) critically depends on reversing false changes.
An asset protected by Blockchain can only be changed by someone who has the key for the most recent change. When your key is stolen and used to publish a false change, that's no longer you... it's the thief. When your key is lost on a crashed hard drive, nobody can publish further changes to the asset. Ever again.
Immutable containers require (1) exhaustive automated testing and (2) ongoing software development for the lifetime of the product, that is the product must be discontinued at the same time as active development.
The first is merely expensive. The second - disallowing the very concept of legacy apps - hasn't demonstrated that it can be sustained over time.
You describe scalable systems, not devops per se. Great if you're a big enough shop working a big enough project to write all the software that way.
When DevOps is done well, it joins development and operations. If you have separate Development, System Administration and DevOps teams, you're doing it wrong so of course you fail.
On the other hand, too much modern devops has reinvented the wheel, improving upon practices which were obsolete 20 years ago. Puppet? Chef? Ansible? Hello rdist and rsh. Crappy then, crappy now. Docker? How the eff do you validate security compliance and successfully patch docker images? You know, the job that in normal VMs gets handled by "yum update." Docker is a security disaster area.
Before everything was connected on the Internet, there were code-generating platforms that let non-programmers assemble common cookie-cutter apps without needing any kind of software development skills. Hypercard, Powerbuilder, things like that. The original author bemoans the loss of these tools.
The problem is: modern software requires security. It must be resilient in the face of somebody actively trying to subvert it. You don't get that from a lego set. You need somebody who has some idea what they're doing.
Anybody can build a building which stands.
Only an engineer can build a building which barely stands.
This. You hire CS majors because they know about the problems you don't know you have and can prevent them from becoming business catastrophes.
Construction doesn't need every carpenter to be an architect but you'd better have an architect.
They tried calling it New Malthus Day but that made the error too obvious.
No, no, you don't understand. He was the LEAD developer.
This Plus. Not only was I underutilized, I was forced to work with a guy who was not just incompetent but willfully ignorant.
How ignorant, you ask? His program spawned 14,000 active threads because he kept starting up pools of http workers and fail to stop the old pools before starting up more. When confronted with his mistake he first insisted that the program was running out of memory (not spawning threads). Then he insisted that 14,000 simultaneous threads was completely reasonable. Then he claimed that it was the Java garbage collector's fault and he couldn't control when it would reclaim used threads (hint: the garbage collector doesn't reclaim threads. It reclaims memory when no threads still use it).
Basic income is better than a guaranteed job by a long shot. Working a worthless job is not only soul-crushing, it consumes the time you could have spent bettering yourself so that you can get a real job.
However, I disagree with the concept of a universal basic income. It is morally bankrupt to vote yourself ownership of other people's money. I would prefer to see an optional basic income where any adult citizen is guaranteed a fixed daily stipend, BUT no one who accepts the stipend may vote in federal elections for four years before and after receiving the money.
This would assure that only the folks funding the basic income get to choose how much they're willing to pay. It would give the basic income a fundamental fairness that a universal basic income lacks.
Incidentally, have you considered the numbers? There are somewhere around 250 million adult US citizens. Paying them each the poverty threshold income of just over $15,000 per year would cost just under 4 trillion dollars a year. It would be hugely expensive, around 20% of the GDP.
Maybe a decade ago, but if you're building a web app on hardware more constrained than the $10 Raspberry Pi Zero these days then you're probably doing it wrong.
Also, I don't know where you get the idea that Apache apr saves you from buffer overflows. You're still working with char*'s.
If you're building a web app in C, you're probably doing it wrong. C's runtime efficiency is unparalleled but its prone to buffer bounding mistakes and writing successful C code is slow. Your time as a software developer is generally more valuable than the servers which will run it and there are at least half a dozen mainstream languages that permit a convenient, fast job of the kinds of tasks typical of a web app.
Your claim is similar to saying that a hot dog is not cooked well because it's not an omelette.
If you put a hot dog on a bun and hand it to the customer without first grilling or microwaving or somehow warming it up, it's edible but it's not cooked well. More to the point, it is very unlikely to be what the customer desires.
It's equally obvious that the default for a USB-based filesystem should be that it's in a state ready to be disconnected unless a user space program is blocked writing to it right this moment.
If you want a USB raid for manipulating video files, you can set the drive to use non-default options.
Lol. And which language, pray tell, do you like?
Do you?
The buffer is where the data sits while waiting for the receiver to finish receiving and accept it. The write() call can return immediately while the OS sends data from the buffer in the background. The write call can block until the OS finishes sending data from the buffer. Either way there's a buffer that holds the data being sent until the OS is done with it.
This.
There aren't a lot of bad C developers. Bad developers can't get their C programs to work at all (let alone correctly), so they move on to another language.
Bad Java developers abound. Not because Java is a bad language, quite the contrary. But lousy developers can swallow exceptions and muddle along with code that more or less does what it's supposed to. Java protects them from the core dump.
Perl's approach to regular expressions is still superior to my mind. Also, using whitespace in code for any purpose other than readability is insane.
If I break into a server and find everything compiled then all I have is some compiled binaries.
Unless you're writing in C (and if you're building a web app, you probably aren't) the object code tends to decompile into a pretty close copy of the original source minus the comments. If you thought Java meant you couldn't get back to the source code, think again.
If your operating system was programmed well, the IO call writing to the USB drive would not return until all write buffers were flushed, would not permit large write buffers to a USB drive -and- nothing else would attempt to write the USB drive in the background.
Your operating system was not programmed well. Quick Removal only gets close.
Indeed. Those system administrators are failures too, all but begging for hackers to get a toehold inside their main security perimeter.
This!
It's easy in linux to make the program directory unwritable by the program and the data directory unexecutable. Same for ram: easy to mark the program memory read-only and the data memory non-executable.
So how is this extraneous code successfully getting executed?
Generally speaking, if you gain continuous control of a previously unclaimed location, that location belongs to you. Planting a flag is not sufficient. Planting a person is, but only for the area over which that person is capable of exerting control.
Treaty or no treaty, the parts of the moon will go the same way.