My own server should actually be more trusted because there are no third-parties in control who may have reason (bribes, malice, government warrants, etc.) to impersonate me.
But I have no idea how competently you're administering the server that provides that identity warranty. For all I know, it's been rooted by some scum from backwater Nigeria without you being aware of this. The large providers are at least more likely to try to not get hosed that way; their incentives definitely don't include getting hacked by ordinary criminals as a goal...
The only exceptions that I will accept as reasonable are a very narrow area regarding national security.
You shouldn't really accept that there except in a very limited sense: that it may take a decade (or perhaps a little more) for information about military operations to come out. That's enough time for the info to be of little use to the enemy, while still preserving the fundamental aspect of being able to discover what happened within the lifetime of (most) people who were around when it happened and to hold those who made bad decisions to account.
Not to mention that some of the older shows cold be insanely long. War Games was over 4 hours in its entirety. One of the lost Hartnell/Dalek episodes was 5 hours.
Dr. Who used to be structured as having relatively short seasons with each season devoted to a single story arc. The individual episodes would each end with a cliffhanger of some kind, so as to suck people into watching the rest of the season. (I can't remember if the individual episodes were shorter back then; I wasn't paying attention to that when I was that young.)
Well ARM is a hell of a lot less power using but it is also a hell of a lot less powerful clock for clock, so it evens out doesn't it?
The ARM does more than x86 per Watt but less per clock. What this means is that which is best depends entirely on what your bottleneck is. If you're cooling-limited (which a lot of installations are, especially when it comes to servers; getting the heat out of the racks and out of the building is the limiting factor) then the ARM looks a lot sweeter because it allows you to pack processors in much more densely. That in turn saves massively.
OTOH, if you're not cooling-limited (and not in a low-power situation like a hand-held device of course) then the x86 makes a lot more sense, as they're fast, pretty cheap and have multiple very well supported toolchains. Those aren't things to be sniffed at.
4.5 hours is still about 4 times what I get on my laptop
Come on, be sensible! Either your battery's hosed and should be replaced, or you need to stop using that laptop with high-performance-computing class loads. Whichever it is, you're doing something wrong...
What this means for most places is "you should not support https". How is this more secure?
That's indeed not more secure. But what it actually shows is that too many sites are being run and/or managed by fuckwits with room-temperature IQs who shouldn't be running a warm bath, let alone a website! Time to call it for what it is; a website has to be configured correctly to be adequately secure, and to pretend that you can do that for no cost is just Not Right. It does cost, if not actually very much unless you're quite large (but then you really need it anyway).
To be fair, browsers really ought to also throw up big warning messages when data from a login dialog or password field gets sent via an unsecured connection. That would greatly encourage sites that should be using HTTPS to actually do so. (I vaguely remember some version of Netscape trying to do this, but they moaned for any form data sent over HTTP, which was just plain annoying. It was a warning dialog that everyone would rapidly turn off...)
It's only that way because of those big honking warnings. If browsers silently accepted self-signed certificates, they'd be in a lot more use. By cybercriminals.
If there was a way to get encryption without the lock sign, with SNI and without purchased certificates, you would see mass adoption.
But you've got to identify who you're talking to securely as well, otherwise it's trivial to do a man-in-the-middle attack. Having a secure conversation with Anonymous (a.k.a. Dmitry-From-Moscow) won't usually help you.
In theory, it would be OK to just remember the server's cryptographic identity from last time and compare against that, except that it's vital to be able to change the server's certificate from time to time (e.g., because the server got hacked) and that still doesn't help you the first time you contact the service. Bootstrapping trust is hard, and the most workable approach for most folks seems to be the tree of CAs we have now; everything else is either less secure (!) or so utterly hostile to users that you might as well forget it. You don't want false alarms from security components thrust in users faces, and I've yet to meet a real Security Geek who truly appreciated that (I know and work with a few who meet that description).
Problem is: when I look at your python code, I don't know if I'm looking at spaces, or tabs, or some combination of both. Not without a hex dump, or something.
Anyone mixing spaces and tabs in python (or haskell) code deserves exactly what they get. Luckily, code editors in python mode will normalize spacing to use one or the other, precisely because it's a pain to mix them. (I don't particularly care for Python — it doesn't work in the way I prefer to think — but attacking it over the syntactic way it does blocks is pretty dumb. Unless you're insisting on using Notepad.exe to write code, but that'd just be very dumb anyway.)
Too many classes don't implement it that should (and far too many don't narrow the return type correctly!) but thinking about shallow vs deep copies is something you have to do anyway in any language with mutable-model values. That's because you've got to decide when to preserve identity of the contained values and when to duplicate it, and there's no real shortcut to it.
Languages where all values are formally immutable are much simpler in this regard. Either they require you to make a copy when doing an update, or they only allow an in-place update when nobody else is looking, both of which are conceptually similar (and the latter can be fast too, despite taking more code to implement).
Snarky little comment too: do you really think a telco in the non-industrialised world would use ~Twitter~ of all things?
Why not? They're apparently skipping over some of the intervening steps in technological development (e.g., going straight to wireless telecoms because it means less cost with rolling out copper cables/fiber).
The only reason we use AC at all is because that's how it comes out of the generators and it can be transformed to different voltages easily.
That really depends on the design of the generators; there are both AC and DC versions (and which would prevail was the subject of the War of Currents back in the late 19th century). Nowadays, which is used depends very much on the application area, and there are differences between parts of the world too.
For electricity transmission, the big advantage of AC is that converting between voltages is relatively easy via a transformer – a pretty efficient device in the first place – so you can afford to run a large part of your network at elevated voltage (with consequent reduction in power loss), whereas the big advantage of DC is that it doesn't have nearly the same impedance problems on longer power lines. It's also vital to use DC when bridging between electricity Grids, since that means you don't have to match the phases.
They'd actually be better off using 172.16/16 as it looks more real and yet is less likely to be seen in practice (most places that use private ranges either use 10/8 or 192.168/16 for some reason) while still being non-routable.
Or they could use 224/4 and watch all hell break loose.:-)
It's the "get exclusive rights to develop something, but DON'T. then wait FIFTEEN YEARS and then try to sue everyone else for fifteen years worth of damages." That kind of shit needs to be cracked down on. Hard.
Well, laches means that they'll get the court not upholding their suits in the first place (or at least not getting big payouts). If you own a patent, you've got to take at least some steps to defend it (such as contacting potential infringers at the first practical opportunity). Submarining is very frowned-upon.
Sure, but the point is that there *ARE* things there to "poke at"
Sure, but a lot of users don't poke at things "in case they break something". To them, it's the magical mystery machine.
Doing a good user interface, whether a CLI or a GUI, is difficult. It requires thinking about what users actually do and how they actually think. The advantage that many CLIs have is merely that the people developing them are part of the target community of users. (That's a huge advantage!)
Why should it matter? If the one operating at 0.5 gets 1.2 for a few microseconds what harm is done other than a bit more power used for that time?
IIRC, its going from the low-voltage to the high-voltage domain that's awkward; it's all too easy for the bits to not register properly. The other direction is no problem since you're going into a transistor immediately that is (of course) rated for the input.
In their graph they are actually predicting user demand, how are they gonna achieve this in real life?
That might actually be possible given the very short spin-up time, e.g., by scanning the prefetch queue for expensive operations (e.g., floating point multiply and divide) so that you can up the power while the operands for them are still being fetched. It's also not a disaster if the power is a bit low; the chip just goes a little bit slower for a short time.
I've been to a few such conferences. The trips were paid for by the university so I took them as unofficial perks to alleviate the low researcher pay.
Didn't find them useful, though. There are easier ways to pick up the proceedings.
In that case you've missed out on the whole real reason for going to them; the chance to meet up with and talk with other folks in your field. It's rare that a conference is truly worth it for the talks — there are exceptions, but they're really unusual — and it's better to read the proceedings in your own time, but being able to find out what's really going on, hear the latest gossip, associate a face and manner with someone you've corresponded with, and perhaps have a party too, well, that's all really worthwhile.
It's a primate thing I suspect, but while chimps go in for mutual grooming, researchers have conferences.
It takes 3 months of training and guided hands-on programming to be not dangerous on that platform, 6 months to be basically competent and 12 months to be any good.
Hmm, it sounds like you've got a truly terrible mess there, one that needs serious refactoring. The aim should be to get it so that you can get useful work out of a new hire in around 6 months (and mainly non-dangerous in under a month). Of course, that might well take a lot of work to get it to that point, but it'll be worth it since it will improve things for all the rest of you as well...
My older MacBook Pro, for example, has fiber-optic connections embedded in the 2.5mm Line In and Headphone jacks.
Minor correction: those are 3.5mm sockets on that machine (just like on virtually every other computer out there). The 2.5mm jacks (which I've actually got a few of; that's how I know this) are much smaller.
Yes you can write bad code in PHP, that would allow an SQL attack. You can do the same in almost any language.
The issue isn't that you can blow your leg off in any language. The issue is that PHP does the equivalent of putting a big flashing red button in and daring developers not to press it. To be clear, the problem with PHP is that it was traditionally far harder to Do It Right than to Do It Wrong (a recipe for disaster in the hands of non-experts, and even sometimes experts) and that when you got it wrong, it still would work with the sort of input data that most people test with. It's just one giant collection of landmines, waiting to go off. (Maybe these things are fixed now, but there's a metric buttload of tutorials and books out there that still teach the bad old ways. Bad habits have a disturbingly large half-life...)
NFS mounts, since they are intended to mimic disks, are also considered fast devices. However, in the event of a server failure, an NFS disk can take minutes to eventually return success or failure to the application. A program using data on an NFS mount, however, can remain in an uninterruptable state until a final timeout occurs.
That reminds me of an old NFS server back where I used to work, many years ago. That server was serving the main applications partition (/usr IIRC) to a few hundred Sun machines across the department, and to cut a long story short, it was feeling "poorly". I don't know what exactly was wrong hardware-wise, but the net effect was that the machine would reboot from time to time and all of those few hundred client machines would screech to a halt while waiting for almost the whole of their user-space to become available once more. Ouch.
For added fun, it turned out that the machine would do its unscheduled reboot and decide that the lack of a clean shutdown meant that it had to fsck. On the hardware of the time, this was around 30 minutes. Double ouch.
With the reboot done, the nfsd would start again and advertise that the mounts were all available once more. At that point, the 300 or so client machines would all jump in at once to page in all the applications that had been waiting. This would cause the load on the server to spike massively, and trigger the hardware problem again after 30 to 60 seconds or so. That's when it would trigger the whole damn cycle again. Quadruple ouch!
On the plus side, it made it very easy to persuade the head of the department to spring for a whole cluster of brand new fileservers. It's an ill wind that blows no good at all.
Slashdot Mirror
My own server should actually be more trusted because there are no third-parties in control who may have reason (bribes, malice, government warrants, etc.) to impersonate me.
But I have no idea how competently you're administering the server that provides that identity warranty. For all I know, it's been rooted by some scum from backwater Nigeria without you being aware of this. The large providers are at least more likely to try to not get hosed that way; their incentives definitely don't include getting hacked by ordinary criminals as a goal...
The only exceptions that I will accept as reasonable are a very narrow area regarding national security.
You shouldn't really accept that there except in a very limited sense: that it may take a decade (or perhaps a little more) for information about military operations to come out. That's enough time for the info to be of little use to the enemy, while still preserving the fundamental aspect of being able to discover what happened within the lifetime of (most) people who were around when it happened and to hold those who made bad decisions to account.
Not to mention that some of the older shows cold be insanely long. War Games was over 4 hours in its entirety. One of the lost Hartnell/Dalek episodes was 5 hours.
Dr. Who used to be structured as having relatively short seasons with each season devoted to a single story arc. The individual episodes would each end with a cliffhanger of some kind, so as to suck people into watching the rest of the season. (I can't remember if the individual episodes were shorter back then; I wasn't paying attention to that when I was that young.)
Well ARM is a hell of a lot less power using but it is also a hell of a lot less powerful clock for clock, so it evens out doesn't it?
The ARM does more than x86 per Watt but less per clock. What this means is that which is best depends entirely on what your bottleneck is. If you're cooling-limited (which a lot of installations are, especially when it comes to servers; getting the heat out of the racks and out of the building is the limiting factor) then the ARM looks a lot sweeter because it allows you to pack processors in much more densely. That in turn saves massively.
OTOH, if you're not cooling-limited (and not in a low-power situation like a hand-held device of course) then the x86 makes a lot more sense, as they're fast, pretty cheap and have multiple very well supported toolchains. Those aren't things to be sniffed at.
4.5 hours is still about 4 times what I get on my laptop
Come on, be sensible! Either your battery's hosed and should be replaced, or you need to stop using that laptop with high-performance-computing class loads. Whichever it is, you're doing something wrong...
What this means for most places is "you should not support https". How is this more secure?
That's indeed not more secure. But what it actually shows is that too many sites are being run and/or managed by fuckwits with room-temperature IQs who shouldn't be running a warm bath, let alone a website! Time to call it for what it is; a website has to be configured correctly to be adequately secure, and to pretend that you can do that for no cost is just Not Right. It does cost, if not actually very much unless you're quite large (but then you really need it anyway).
To be fair, browsers really ought to also throw up big warning messages when data from a login dialog or password field gets sent via an unsecured connection. That would greatly encourage sites that should be using HTTPS to actually do so. (I vaguely remember some version of Netscape trying to do this, but they moaned for any form data sent over HTTP, which was just plain annoying. It was a warning dialog that everyone would rapidly turn off...)
It's only that way because of those big honking warnings. If browsers silently accepted self-signed certificates, they'd be in a lot more use. By cybercriminals.
You can pick up a single site SSL certificate for under $20 and a wildcard certificate for about $100.
Also $100 is a pretty steep jump in costs for a low/no traffic website.
Why would a low/no traffic website go for a wildcard certificate?
If there was a way to get encryption without the lock sign, with SNI and without purchased certificates, you would see mass adoption.
But you've got to identify who you're talking to securely as well, otherwise it's trivial to do a man-in-the-middle attack. Having a secure conversation with Anonymous (a.k.a. Dmitry-From-Moscow) won't usually help you.
In theory, it would be OK to just remember the server's cryptographic identity from last time and compare against that, except that it's vital to be able to change the server's certificate from time to time (e.g., because the server got hacked) and that still doesn't help you the first time you contact the service. Bootstrapping trust is hard, and the most workable approach for most folks seems to be the tree of CAs we have now; everything else is either less secure (!) or so utterly hostile to users that you might as well forget it. You don't want false alarms from security components thrust in users faces, and I've yet to meet a real Security Geek who truly appreciated that (I know and work with a few who meet that description).
Problem is: when I look at your python code, I don't know if I'm looking at spaces, or tabs, or some combination of both. Not without a hex dump, or something.
Anyone mixing spaces and tabs in python (or haskell) code deserves exactly what they get. Luckily, code editors in python mode will normalize spacing to use one or the other, precisely because it's a pain to mix them. (I don't particularly care for Python — it doesn't work in the way I prefer to think — but attacking it over the syntactic way it does blocks is pretty dumb. Unless you're insisting on using Notepad.exe to write code, but that'd just be very dumb anyway.)
Implementing clone() in Java is a pain
Too many classes don't implement it that should (and far too many don't narrow the return type correctly!) but thinking about shallow vs deep copies is something you have to do anyway in any language with mutable-model values. That's because you've got to decide when to preserve identity of the contained values and when to duplicate it, and there's no real shortcut to it.
Languages where all values are formally immutable are much simpler in this regard. Either they require you to make a copy when doing an update, or they only allow an in-place update when nobody else is looking, both of which are conceptually similar (and the latter can be fast too, despite taking more code to implement).
Snarky little comment too: do you really think a telco in the non-industrialised world would use ~Twitter~ of all things?
Why not? They're apparently skipping over some of the intervening steps in technological development (e.g., going straight to wireless telecoms because it means less cost with rolling out copper cables/fiber).
The only reason we use AC at all is because that's how it comes out of the generators and it can be transformed to different voltages easily.
That really depends on the design of the generators; there are both AC and DC versions (and which would prevail was the subject of the War of Currents back in the late 19th century). Nowadays, which is used depends very much on the application area, and there are differences between parts of the world too.
For electricity transmission, the big advantage of AC is that converting between voltages is relatively easy via a transformer – a pretty efficient device in the first place – so you can afford to run a large part of your network at elevated voltage (with consequent reduction in power loss), whereas the big advantage of DC is that it doesn't have nearly the same impedance problems on longer power lines. It's also vital to use DC when bridging between electricity Grids, since that means you don't have to match the phases.
They'd actually be better off using 172.16/16 as it looks more real and yet is less likely to be seen in practice (most places that use private ranges either use 10/8 or 192.168/16 for some reason) while still being non-routable.
Or they could use 224/4 and watch all hell break loose. :-)
This is most noticeable in their wimpy definition of a pint.
Except their definition of fluid ounce is also different. Stick with liters to stay sane!
It's the "get exclusive rights to develop something, but DON'T. then wait FIFTEEN YEARS and then try to sue everyone else for fifteen years worth of damages." That kind of shit needs to be cracked down on. Hard.
Well, laches means that they'll get the court not upholding their suits in the first place (or at least not getting big payouts). If you own a patent, you've got to take at least some steps to defend it (such as contacting potential infringers at the first practical opportunity). Submarining is very frowned-upon.
Sure, but the point is that there *ARE* things there to "poke at"
Sure, but a lot of users don't poke at things "in case they break something". To them, it's the magical mystery machine.
Doing a good user interface, whether a CLI or a GUI, is difficult. It requires thinking about what users actually do and how they actually think. The advantage that many CLIs have is merely that the people developing them are part of the target community of users. (That's a huge advantage!)
Why should it matter? If the one operating at 0.5 gets 1.2 for a few microseconds what harm is done other than a bit more power used for that time?
IIRC, its going from the low-voltage to the high-voltage domain that's awkward; it's all too easy for the bits to not register properly. The other direction is no problem since you're going into a transistor immediately that is (of course) rated for the input.
In their graph they are actually predicting user demand, how are they gonna achieve this in real life?
That might actually be possible given the very short spin-up time, e.g., by scanning the prefetch queue for expensive operations (e.g., floating point multiply and divide) so that you can up the power while the operands for them are still being fetched. It's also not a disaster if the power is a bit low; the chip just goes a little bit slower for a short time.
I've been to a few such conferences. The trips were paid for by the university so I took them as unofficial perks to alleviate the low researcher pay.
Didn't find them useful, though. There are easier ways to pick up the proceedings.
In that case you've missed out on the whole real reason for going to them; the chance to meet up with and talk with other folks in your field. It's rare that a conference is truly worth it for the talks — there are exceptions, but they're really unusual — and it's better to read the proceedings in your own time, but being able to find out what's really going on, hear the latest gossip, associate a face and manner with someone you've corresponded with, and perhaps have a party too, well, that's all really worthwhile.
It's a primate thing I suspect, but while chimps go in for mutual grooming, researchers have conferences.
It takes 3 months of training and guided hands-on programming to be not dangerous on that platform, 6 months to be basically competent and 12 months to be any good.
Hmm, it sounds like you've got a truly terrible mess there, one that needs serious refactoring. The aim should be to get it so that you can get useful work out of a new hire in around 6 months (and mainly non-dangerous in under a month). Of course, that might well take a lot of work to get it to that point, but it'll be worth it since it will improve things for all the rest of you as well...
My older MacBook Pro, for example, has fiber-optic connections embedded in the 2.5mm Line In and Headphone jacks.
Minor correction: those are 3.5mm sockets on that machine (just like on virtually every other computer out there). The 2.5mm jacks (which I've actually got a few of; that's how I know this) are much smaller.
Yes you can write bad code in PHP, that would allow an SQL attack. You can do the same in almost any language.
The issue isn't that you can blow your leg off in any language. The issue is that PHP does the equivalent of putting a big flashing red button in and daring developers not to press it. To be clear, the problem with PHP is that it was traditionally far harder to Do It Right than to Do It Wrong (a recipe for disaster in the hands of non-experts, and even sometimes experts) and that when you got it wrong, it still would work with the sort of input data that most people test with. It's just one giant collection of landmines, waiting to go off. (Maybe these things are fixed now, but there's a metric buttload of tutorials and books out there that still teach the bad old ways. Bad habits have a disturbingly large half-life...)
NFS mounts, since they are intended to mimic disks, are also considered fast devices. However, in the event of a server failure, an NFS disk can take minutes to eventually return success or failure to the application. A program using data on an NFS mount, however, can remain in an uninterruptable state until a final timeout occurs.
That reminds me of an old NFS server back where I used to work, many years ago. That server was serving the main applications partition (/usr IIRC) to a few hundred Sun machines across the department, and to cut a long story short, it was feeling "poorly". I don't know what exactly was wrong hardware-wise, but the net effect was that the machine would reboot from time to time and all of those few hundred client machines would screech to a halt while waiting for almost the whole of their user-space to become available once more. Ouch.
For added fun, it turned out that the machine would do its unscheduled reboot and decide that the lack of a clean shutdown meant that it had to fsck. On the hardware of the time, this was around 30 minutes. Double ouch.
With the reboot done, the nfsd would start again and advertise that the mounts were all available once more. At that point, the 300 or so client machines would all jump in at once to page in all the applications that had been waiting. This would cause the load on the server to spike massively, and trigger the hardware problem again after 30 to 60 seconds or so. That's when it would trigger the whole damn cycle again. Quadruple ouch!
On the plus side, it made it very easy to persuade the head of the department to spring for a whole cluster of brand new fileservers. It's an ill wind that blows no good at all.