Your friend sounds like he has some serious anger management issues.
goto used sparingly can be a useful tool for breaking out of multiple layers of structures and going to an error handling block when an error happens in an inner loop and avoids adding loads of boilerplate to every layer of the nesting just to deal with error conditions. This is especially true in a language like C which does not have exceptions.
However care is needed to avoid jumping over things you didn't mean to jump over (like cleanup code) and over-use of goto can result in seriously unreadable spaghetti code. This makes some programmers anti-goto.
While it might be nice to use a safe(r) language, can't we at least have a compile option in C that adds bounds checking?
Not really for the general case.
In a normal C compiler when a pointer is passed from one function to another, stored in a field of a structure, stored in a global variable etc no information about the start and end of the memory block it points to is stored/passed along with it.
In theory you could have a C compiler that used extended pointers which stored start and end information along with the pointer itself. In practice however such a C compiler would have several issues that would prevent it being widely used. Firstly it would be ABI incompatible with the standard C compiler, so you'd either have to build your whole OS and every app with this compiler or keep two paralell libraries sets. Secondly it would break assumptions that a lot of code makes about the size of pointers and their convertibility to/from intergers. Thirdly it would massively increase memory use.
There have been partial solutions for special cases which provide special versions of system functions that are commonly used in an unsafe manner then modify calls to those functions for the cases where the compiler does know the buffer size (e.g. because the buffer is a local variable) but they are far from a perfect fix. .
And while it has a "select" function it's not much use in practice because it can ONLY select on sockets, so you end up with windows specific event and/or thread handling as well.
But better... If it was good enough people would use it out of habit.
Unfortunately all attempts at making remote manipulation devices both mechanical and electronic have resulted in things that are far more cumbersome than using your hands directly. The human arm and hand is an amazingly good maniupulator with extremely good feedback so it can grasp something firmly without damaging it.
There is usually a way to clamp the workpeice and keep your fingers out of harms way but it's slower and more cumbersome than just holding it and people have a nasty habit of getting overconfident in the own ability to not slip up.
There are boards that are faster than the Pi and boards that are cheaper but I haven't seen anyone come out with a board that is both faster and cheaper.
The networks are a risk but they are a risk that can be mitigated to at least some extent by strong well-managed encryption (and yes this does mean avoiding the easy to use centralised systems where the system operator manages the encryption and going for something more decentralised and that requires more work and understanding but lets you manage the encryption yourself).
But if the end devices are compromised then the keys can be stolen or the data can simply be copied before it is encyrpted.
btrfs brings really useful features like data integrity protection through the combination of checksums with either multiple copies or error correction codes*, snapshotting** and the ability to create a logical copy of a file without creating a physical copy. These are features that most other linux fileystems don't have. You can find out more at https://btrfs.wiki.kernel.org/...
Unfortunately it's hard to take a filesystem, particularly a complex one like btrfs from "seems to work fine under our lab tests" to "proven stable in production" . devs need data from real world problems to improve the filesystem but to get data from real world problems requires people to run it on real world systems but people are reluctant to put an experimental filesystem on their production servers.
This is good news towards the goal of turning btrfs into a "proven stable in production" soloution.
* The trouble with conventional raid is it keeps multiple effective copies but it has no idea which of those copies is correct. So it relies on the underlying drives to return either correct data or an error code. Experiance has shown that the checksum systems built into drives are not strong enough to completely prevent bad data from being returned. ** Yes you can do snapshotting with a layer like lvm between the filesystem and the storage but there are distinct advantages to doing it as part of the filesystem.
If you know that, why haven't you bet the farm shorting bitcoin?
AIUI many shorting contracts require you to cover your short once your losses reach a certain level. You can still lose even if you turn out to be ultimately right.
If the government decides to make trade in bitcoin difficult then government will have little trouble doing so through laws and regulations. It's already illegal in some countries. Want to risk jail time to use bitcoin?
While governments can sometimes go after individual users doing so on any significant scale carries a very high political cost. It's much easier to paint a handful of people who form a competing central authority as "criminals" and shut them down than it is to go after everyone participating in making a decentralised system work.
Which is not to say it's impossible for governments to crush bitcoin just much harder for them to do it than to crush comparable centralised schemes.
It seems to have some geek appeal but there isn't anything functionally novel about what it does.
What is novel about bitcoin is it does what it does without requiring a central authoritiy. People who have tried to make "alternative money" systems with a central authority have found themselves either crushed or subsumed into the regulated system where the government can tell you who you may or may not give money to or order transactions reversed long after the fact.
The only real way these guilds could lock out the little guy is if they controlled more than 50% of the overall processing power, but then they could do much worse things.
According to blockchain.info the top three mining pools between them control over 54% of the total mining power add number four and you get up to 67%.
So if they were to team up into a cartel they could arbiterally prevent blocks they didn't like from staying in the blockchain. The interesting question is if the leaders of the guilds decided to do this to enforce higher transaction fees would their members go along with it or would they break ranks in sufficient numbers to negate the affect?
as there will be far fewer miners once there are no more bitcoins to be mined, so difficulty will fall, and they will get a larger share of the perhaps larger transaction fees.
So you have a scenario where miners are giving up and the toal network hashrate (and hence the difficulty) is falling. This means two things.
1: The ammount of hashing power needed for a 51% attack goes down 2: The ammount of mining hardware available on the likes of ebay at knockdown prices goes up.
Combine the two and it potentially becomes a lot more economical to amass enough mining power to do a 51% attack.
The motives of the attacker could be varied. It could be a government who wants to destroy bitcoin. It could also be done by someone (or a cartel) for "buisness" reasons (if you control 51% of the hashing power you can enforce a minimum transaction fee by refusing to accept any blocks that contain transactions with lower fees).
Of course the problem with placebos is that they essentially require lying to the patient. If you are honest and actually tell the patient "it's just a sugar pill" then it's not going to have any affect.
Which is why you get things like homeopathy dressing up placebos in some BS that sounds plausible to the uneducated.
The only people who will have reason to run a miner are the people who use bitcoins as a currency
You forgot those trying to do a "51% attack" for the purposes of killing or controlling bitcoin.
If mining rewards drop signinficantly and consequently lots of miners quit then said attacks will get easier both because they will require less hashing power and because there is likely to be a lot of uses mining hardware turning up on ebay at knockdown prices.
Sure such a system works well for slow moving carts but i'm not sure it would work so well for a car. For best milage you really want to avoid actively braking (even regenerative) as much as possible. Your proposal would make it very difficult to express to the car "I want to coast not actively putting power in but not actively taking it out either".
I'd also be worried about whether a speed pedal would be fine enough control to correctly select the desired speed over the wide range a car operates over.
What matters for avoiding blocks is not merely having lots of addresses, it's having lots of addresses spread out through the address space so that people can't effectively block you without either causing massive collateral damage or painstakingly hunting down your addresses.
Another approach is to create fictional IDs with generic email addresses (gmail or similar), create keys for the fictional IDs and get them signed. Then use the keys associated with fictional IDs to sign the keys you plan to use for impersonation.
This is more work than just having shady people use their real IDs to sign the impersonation keys but reduces the risk of your accomplices being found out.
Which if you think about it, means you should probably release the extreme version first dummies.
Ever noticed how intel have recently been using misleading part numbers to make it less obvious that their high end parts are a generation behind their mainstream parts?
And yeah, maybe those cheap meters read 1000V or something - apply 1000V to them and they'll explode because they aren't rated to.
I've pushed a cheap multimeter to the point it was showing "reading off scale" on the 1000V range and it didn't explode.....................
Afaict the problem with these cheap meters is not that they can't read 1000V safely in a low energy environment, it's that power distribution systems have large ammounts of energy available combined with spikes that go well over the nominal voltage. The spikes can blow out a cheap meter and then massive ammounts of energy can flow through the arc that the spike created.
Having said that a good set of fused test leads with HRC fuses will give you a lot of protection even if your meter is crap.
The only way you could still buy XP was to have it pre-installed on a tiny portable that was incapable of running any other MS product.
You could also buy machines that had a windows vista buisness (or ultimate if you wanted to throw money away) license but had XP pro installed under downgrade rights.
It sounds like your problem was not that you were using windows but that you had a crappy contract with your vendor that was somehow tying the version of windows you were running to the replacement of your hardware far more closely than it needed to be.
16GB regsitered ECC DDR3 server modules are only $158 according to newegg but at least on the intel side you need a server board and CPU to use them.
16GB unregsitered non-ecc desktop DDR3 modules are another matter. Afaict only one specialist manufacturer has announced that they are making them and when I google the part number they list I don't find anywhere actually selling it. Also from what I have read the standard init code that intel gives to bios manufacturers doesn't support 16GB modules and it is unclear whether it will ever be updated to do so.
Note that regsitered ECC modules can be quad rank while desktop modules are limited to dual rank. So a 16GB server module needs 4Gb chips while a 16GB desktop module needs 8Gb chips. A 32GB server module uses 8Gb chips and costs about $750 according to crucial which IMO gives a clue as to how expensive 16GB desktop modules are likely to be if and when they become available for purchase.
I'm not convinced of that, there may be a handful of apps that are written directly to target wayland or mir but for the most part I would expect apps to continue to use toolkits like qt and gtk which afaict will support multiple backends.
Apps that use x directly or use an older/more obscure toolkit that only has an x backend will be supported on mir and wayland through thier x compatibilty layers.
The thing is when you look more closely you find that most of those processes are spending most of their time asleep. So there is little to be gained from more than 2 cores (one for the program you actually care about, one for the background crap) unless the program you actually care about can effectively spread it's work across multiple threads*.
* There are a lot of processes that have multiple threads but only use one of them at a time to do significant work.
Slashdot Mirror
Your friend sounds like he has some serious anger management issues.
goto used sparingly can be a useful tool for breaking out of multiple layers of structures and going to an error handling block when an error happens in an inner loop and avoids adding loads of boilerplate to every layer of the nesting just to deal with error conditions. This is especially true in a language like C which does not have exceptions.
However care is needed to avoid jumping over things you didn't mean to jump over (like cleanup code) and over-use of goto can result in seriously unreadable spaghetti code. This makes some programmers anti-goto.
While it might be nice to use a safe(r) language, can't we at least have a compile option in C that adds bounds checking?
Not really for the general case.
In a normal C compiler when a pointer is passed from one function to another, stored in a field of a structure, stored in a global variable etc no information about the start and end of the memory block it points to is stored/passed along with it.
In theory you could have a C compiler that used extended pointers which stored start and end information along with the pointer itself. In practice however such a C compiler would have several issues that would prevent it being widely used. Firstly it would be ABI incompatible with the standard C compiler, so you'd either have to build your whole OS and every app with this compiler or keep two paralell libraries sets. Secondly it would break assumptions that a lot of code makes about the size of pointers and their convertibility to/from intergers. Thirdly it would massively increase memory use.
There have been partial solutions for special cases which provide special versions of system functions that are commonly used in an unsafe manner then modify calls to those functions for the cases where the compiler does know the buffer size (e.g. because the buffer is a local variable) but they are far from a perfect fix.
.
And while it has a "select" function it's not much use in practice because it can ONLY select on sockets, so you end up with windows specific event and/or thread handling as well.
But better... If it was good enough people would use it out of habit.
Unfortunately all attempts at making remote manipulation devices both mechanical and electronic have resulted in things that are far more cumbersome than using your hands directly. The human arm and hand is an amazingly good maniupulator with extremely good feedback so it can grasp something firmly without damaging it.
There is usually a way to clamp the workpeice and keep your fingers out of harms way but it's slower and more cumbersome than just holding it and people have a nasty habit of getting overconfident in the own ability to not slip up.
There are faster, cheaper boards than the Pi.
There are boards that are faster than the Pi and boards that are cheaper but I haven't seen anyone come out with a board that is both faster and cheaper.
Looks like it's still arround.
The networks are a risk but they are a risk that can be mitigated to at least some extent by strong well-managed encryption (and yes this does mean avoiding the easy to use centralised systems where the system operator manages the encryption and going for something more decentralised and that requires more work and understanding but lets you manage the encryption yourself).
But if the end devices are compromised then the keys can be stolen or the data can simply be copied before it is encyrpted.
btrfs brings really useful features like data integrity protection through the combination of checksums with either multiple copies or error correction codes*, snapshotting** and the ability to create a logical copy of a file without creating a physical copy. These are features that most other linux fileystems don't have. You can find out more at https://btrfs.wiki.kernel.org/...
Unfortunately it's hard to take a filesystem, particularly a complex one like btrfs from "seems to work fine under our lab tests" to "proven stable in production" . devs need data from real world problems to improve the filesystem but to get data from real world problems requires people to run it on real world systems but people are reluctant to put an experimental filesystem on their production servers.
This is good news towards the goal of turning btrfs into a "proven stable in production" soloution.
* The trouble with conventional raid is it keeps multiple effective copies but it has no idea which of those copies is correct. So it relies on the underlying drives to return either correct data or an error code. Experiance has shown that the checksum systems built into drives are not strong enough to completely prevent bad data from being returned.
** Yes you can do snapshotting with a layer like lvm between the filesystem and the storage but there are distinct advantages to doing it as part of the filesystem.
If you know that, why haven't you bet the farm shorting bitcoin?
AIUI many shorting contracts require you to cover your short once your losses reach a certain level. You can still lose even if you turn out to be ultimately right.
If the government decides to make trade in bitcoin difficult then government will have little trouble doing so through laws and regulations. It's already illegal in some countries. Want to risk jail time to use bitcoin?
While governments can sometimes go after individual users doing so on any significant scale carries a very high political cost. It's much easier to paint a handful of people who form a competing central authority as "criminals" and shut them down than it is to go after everyone participating in making a decentralised system work.
Which is not to say it's impossible for governments to crush bitcoin just much harder for them to do it than to crush comparable centralised schemes.
It seems to have some geek appeal but there isn't anything functionally novel about what it does.
What is novel about bitcoin is it does what it does without requiring a central authoritiy. People who have tried to make "alternative money" systems with a central authority have found themselves either crushed or subsumed into the regulated system where the government can tell you who you may or may not give money to or order transactions reversed long after the fact.
bitcoin is to e-gold as gnutella is to napster.
The only real way these guilds could lock out the little guy is if they controlled more than 50% of the overall processing power, but then they could do much worse things.
According to blockchain.info the top three mining pools between them control over 54% of the total mining power add number four and you get up to 67%.
So if they were to team up into a cartel they could arbiterally prevent blocks they didn't like from staying in the blockchain. The interesting question is if the leaders of the guilds decided to do this to enforce higher transaction fees would their members go along with it or would they break ranks in sufficient numbers to negate the affect?
as there will be far fewer miners once there are no more bitcoins to be mined, so difficulty will fall, and they will get a larger share of the perhaps larger transaction fees.
So you have a scenario where miners are giving up and the toal network hashrate (and hence the difficulty) is falling. This means two things.
1: The ammount of hashing power needed for a 51% attack goes down
2: The ammount of mining hardware available on the likes of ebay at knockdown prices goes up.
Combine the two and it potentially becomes a lot more economical to amass enough mining power to do a 51% attack.
The motives of the attacker could be varied. It could be a government who wants to destroy bitcoin. It could also be done by someone (or a cartel) for "buisness" reasons (if you control 51% of the hashing power you can enforce a minimum transaction fee by refusing to accept any blocks that contain transactions with lower fees).
Of course the problem with placebos is that they essentially require lying to the patient. If you are honest and actually tell the patient "it's just a sugar pill" then it's not going to have any affect.
Which is why you get things like homeopathy dressing up placebos in some BS that sounds plausible to the uneducated.
The only people who will have reason to run a miner are the people who use bitcoins as a currency
You forgot those trying to do a "51% attack" for the purposes of killing or controlling bitcoin.
If mining rewards drop signinficantly and consequently lots of miners quit then said attacks will get easier both because they will require less hashing power and because there is likely to be a lot of uses mining hardware turning up on ebay at knockdown prices.
Sure such a system works well for slow moving carts but i'm not sure it would work so well for a car. For best milage you really want to avoid actively braking (even regenerative) as much as possible. Your proposal would make it very difficult to express to the car "I want to coast not actively putting power in but not actively taking it out either".
I'd also be worried about whether a speed pedal would be fine enough control to correctly select the desired speed over the wide range a car operates over.
Twitter can get its own /32 range.
And that whole range can be blocked in one go.
What matters for avoiding blocks is not merely having lots of addresses, it's having lots of addresses spread out through the address space so that people can't effectively block you without either causing massive collateral damage or painstakingly hunting down your addresses.
Another approach is to create fictional IDs with generic email addresses (gmail or similar), create keys for the fictional IDs and get them signed. Then use the keys associated with fictional IDs to sign the keys you plan to use for impersonation.
This is more work than just having shady people use their real IDs to sign the impersonation keys but reduces the risk of your accomplices being found out.
Which if you think about it, means you should probably release the extreme version first dummies.
Ever noticed how intel have recently been using misleading part numbers to make it less obvious that their high end parts are a generation behind their mainstream parts?
And yeah, maybe those cheap meters read 1000V or something - apply 1000V to them and they'll explode because they aren't rated to.
I've pushed a cheap multimeter to the point it was showing "reading off scale" on the 1000V range and it didn't explode.....................
Afaict the problem with these cheap meters is not that they can't read 1000V safely in a low energy environment, it's that power distribution systems have large ammounts of energy available combined with spikes that go well over the nominal voltage. The spikes can blow out a cheap meter and then massive ammounts of energy can flow through the arc that the spike created.
Having said that a good set of fused test leads with HRC fuses will give you a lot of protection even if your meter is crap.
The only way you could still buy XP was to have it pre-installed on a tiny portable that was incapable of running any other MS product.
You could also buy machines that had a windows vista buisness (or ultimate if you wanted to throw money away) license but had XP pro installed under downgrade rights.
It sounds like your problem was not that you were using windows but that you had a crappy contract with your vendor that was somehow tying the version of windows you were running to the replacement of your hardware far more closely than it needed to be.
16GB regsitered ECC DDR3 server modules are only $158 according to newegg but at least on the intel side you need a server board and CPU to use them.
16GB unregsitered non-ecc desktop DDR3 modules are another matter. Afaict only one specialist manufacturer has announced that they are making them and when I google the part number they list I don't find anywhere actually selling it. Also from what I have read the standard init code that intel gives to bios manufacturers doesn't support 16GB modules and it is unclear whether it will ever be updated to do so.
Note that regsitered ECC modules can be quad rank while desktop modules are limited to dual rank. So a 16GB server module needs 4Gb chips while a 16GB desktop module needs 8Gb chips. A 32GB server module uses 8Gb chips and costs about $750 according to crucial which IMO gives a clue as to how expensive 16GB desktop modules are likely to be if and when they become available for purchase.
I'm not convinced of that, there may be a handful of apps that are written directly to target wayland or mir but for the most part I would expect apps to continue to use toolkits like qt and gtk which afaict will support multiple backends.
Apps that use x directly or use an older/more obscure toolkit that only has an x backend will be supported on mir and wayland through thier x compatibilty layers.
The thing is when you look more closely you find that most of those processes are spending most of their time asleep. So there is little to be gained from more than 2 cores (one for the program you actually care about, one for the background crap) unless the program you actually care about can effectively spread it's work across multiple threads*.
* There are a lot of processes that have multiple threads but only use one of them at a time to do significant work.