You mean the same moderating system that hasn't given me mod points in 4 or 5 years?
The slashdot system seems to be relatively hard on people who post one-liner smartass comments all the time. If we look back through your recent history then we don't see a lot that is likely to attract the karma-positive moderations. I suspect it also helps if you include a little context with <quote>s of what you're talking about. Otherwise it is too easy for people doing metamodding to not understand what you're talking about (no, you don't need to quote the whole lot. Just the relevant sentence or two).
The only problem is that a number of shared hosts don't allow for pdo with mysql (or postgres). For example, I use FatCow, and they only have PDO enabled for sqlite, which is the php default setting. I've asked them to change this during their quarterly suggestion review, but they have yet to enable it.
That sounds to me like it is worth considering relocating your business to another facility that does support PDO with mysql and/or postgres. Why put up with bad service when there's someone else who'll be willing to do things properly so you can avoid the pain points?
As long as there is money to be made, viruses will be made. Or power (intelligency agencies).
Money and asshole-dom are the keys to why malware is created. Money is what allows the asses to keep on doing it rather than going off and doing something more worthwhile to earn a living. Only assholes make malware in the first place (yes, I've seen people claiming to be non-asses who are making "non-evil" malware, but I don't trust them and consider them to be part of the group of people I don't want on this system at all anyway).
For the most part, intelligence agencies prefer to watch who you're talking to what you're saying, since traffic analysis is easier than cracking. They don't trust that they'll be able to break into your machine undetected, so they don't rely on being able to do so (well, except in special cases which I'd bet you don't fall into, unless you're really a terrorist).
You seriously believe that Big Brother watches you from a.mil hostname?
Why not? They're arrogant enough to not cover their tracks more thoroughly (after all, it's not like most people would have noticed) and you're dismissive enough. Playing right into their hands.
Maybe so, but it does depend on what your baseline is. They've got a bunch of fascists in charge who hate their (much larger) neighbors more than they hate us. They have no oil to speak of though, nor a navy worth the name to cause trouble in the Red Sea, so we ignore them.
You use different words but the problem is still the same. I'll speak in generic terms.
What happens when the system is compromised and someone else can identify as me? How do I again secure my identity? What do I change? How do I change it?
What happens if someone breaks into the database and swaps around the biometric parts of the records for politicians and known terrorists?
It doesn't seem like any of the ARM based procs support IEEE 754r.
For a long time, they didn't support straight IEEE 754 either, and did all float handling in software. (Don't know if that's changed. At the time I was involved in circuit-level simulation of ARM CPUs, but that was ages ago.)
Which means JUST CHECK IT ONCE at the start of the queue. The 2nd check is completely and utterly pointless. Hell I once realised I'd been showing them the wrong boarding pass, it was only when I went to get on the plane that they pointed it out.
At my airport, they check boarding passes against a computerized list of people who are allowed in the secured area (and have done for a few years now). This is at the start of the line, and there are no further checks on the boarding pass until you're actually going through the gate, presumably then a check to see if you're getting on the right plane. On the other hand, this isn't in the US. (The UK has had restrictive security at airports for many years; 9/11 made little difference here in practice.)
Passports aren't checked on exit until you're actually boarding an international flight, and that looks like a check to see that the name matches the boarding pass and the picture matches the person. I guess that allows those deep checks that they do want to do to be carried out between the time when you buy your ticket and when you get your boarding pass.
If you could hit the back button and instantly be back on the page you were looking at and at the same position of that page, with no reloading and reflowing to mess you up, you wouldn't need tabs to load a quick check of a link. Refresh is a single key-combo away if you need it. It shouldn't be the default. You shouldn't need tabs just to look at three or four links in the middle of a page one at a time.
You seem to be assuming that the only use for tabs is for doing quick checking of links. That's definitely not the only use I put them to (I've currently got 13 long-lived pages open on different tabs and I browse them asynchronously relative to each other). Your assumption only holds for a subset of browsing behavior.
If the code, documentation, and specs disagree, all you know for certain is that for the last 10 years, the code has been running in production this way because that was the last time it was compiled. That doesn't make it right, but you had better find someone to explain it.
If code, docs and specs all disagree then you've got problems. Doubly so if the code doesn't appear to correlate at all with the behavior of the deployed program. I've seen that (someone had patched the binary for unknown reasons...)
When you're working with componentized software, it's more important to be spec driven. This is because the consumers of the code usually work according to the spec (most programmers aren't too keen on having to read someone else's source just to find out how to use it). In those cases, it's also easy to have a feature that is only rarely used and which doesn't work (e.g., by crashing, a clearly undesirable situation). If that happens, you're stuck with working out whether this was a problem of the spec or the implementation or the documentation (i.e., if the component was just called wrong). Sometimes life's like that.
Of course, even better than the spec is having the design theory of the code. That's because it allows you to know how the original author was envisaging evolving things, and it lets you know which parts are just code that was put in to make it work and so can be improved/fixed without trouble. With the design theory, you can even re-derive the spec from first principles. But yes, it's often (even usually) missing, as most junior programmers just don't grasp why it is important and so never write it down.
The fact that a FET is called a FET doesn't mean it is a transistor, any more than the Democratic People's Republic of Korea is democratic, for the people, or a republic.
Ah, you come from the school of redefinition, so you're trying to change the meaning of the word "transistor" to mean what will support your foolish argument. Yes, there are two types of transistor, each with different characteristics that orient towards particular applications (e.g., high-power for BJT, digital logic for FET) but to define only one of them as a "true" transistor just speaks of your ignorance. You must be a sound engineer?
Next up given how weak your argument is, you'll be raising your voice or writing in capitals.
"Perl is more than just the vagaries of syntax. Perl is philosophy; Perl is custom; Perl is architectual edifice; Perl is community."
And Perl6 is a jump over the shark.
I've seen snippets of Perl6 and it does indeed look rather different from previous versions of Perl. Does it stand a good a chance of running lots of existing perl scripts without nasty interop goop? If not, it's really another language and should not hang off Perl's coattails. Call it "Rakudo" instead (after all, that name's used right now) and let it find its own way in the world of languages. If instead they'd stuck to being, say, 95% compatible with existing perl scripts then, while it would have constrained their creativity, it would mean they'd be able to pick up on the wealth of CPAN for little extra effort.
And this is relevant to 99.9% of the software out there how?
It isn't. Now. But if the code is inherited from the "olden days", then those stupid restrictions did matter back then. (I remember Ultrix. How I hated how Ultrix carried out linking. The old Linux a.out system was much nicer, despite being awful.)
Well, let's see... when it's the person who hired you that isn't "fully familiar with arrays", because he's the one that started the company, maybe you can "do the math"....;)
In that case "the math" says to me that it is time to look for another job where the owner won't be sabotaging you with abject stupidity. Just sayin'.
Sounds like you've not done very much maintenance programming. The problem is that the code is often wrong too. So now you've got to figure out what it was supposed to do originally (good luck, the developer's left the company under a cloud and didn't leave a forwarding address) and also what all the clients of the code are expecting it to do (typically at variance with what the code does and what it is supposed to do). At that point, reading the code doesn't help very much. Yes, you know that it is setting certain flags in an indirectly-accessed context by performing a calculation and then XORing the result, but do you know if they are the right flags? Were they ever correct? Did the meaning change from then and the calculation not get updated? Who knows?
External documentation should cover the high-level design of the system; the principles upon which it is all founded. That doesn't change very fast (total replacement of the basic data structure of a program is hard, and rarely done). Comments on the code (plus sensible naming of functions, arguments and variables) should cover how the big picture fits to the local view of what is going on. It's rare indeed that you need blow-by-blow comments on each line of the function; that's when reading the damn code itself ought to suffice. (The code itself only ever says "how"; it never says "why", and only says "who" and "when" in the most cryptic fashion. For maintenance, "why" is the key question.) An objective spec (which can be external, but which most certainly isn't the code) makes it easier to say whether the code is right or wrong, and if wrong, how it can be fixed or improved without causing difficulties. A spec does not need to be long either; lots of functions are characterized by just a line. Refusing to comment at all is just ridiculous and malicious.
These can be comments in code, but SVN (or any SCM) commit comments are also extremely useful for this.
Those tell you who, which is useful for getting back at them when you find that something "clever" was deposited in code you maintain. I know of devs who always commit with a message "fix the bug". Thankfully, they use genuinely good commenting practices or I'd be forced to hunt them down and put them out of my misery.
The advantage of comments is that they're right there in the code when you're looking at it. Commit log messages typically need an extra step to retrieve (especially when you've got a complex and old file, when identifying who committed the core of the code you're looking at, and not just the last change to it).
Also have you see seen the population density and land mass of Europe compared to NA?
You're just making excuses there. Finland has about half the population density of the US, so it would have to have much worse coverage outside the main cities? Norway has about 40% of the density, so it would be even worse still? Well, no. About all that you can really say is that with the US, the national carriers are really big (and they don't offer particularly great coverage anyway in the real backwoods parts, but so?) If you're saying that they have to screw their customers over just because there's a lot of people in the US, then you're just being a shill (paid or unpaid, I know not which) for the carriers.
The real problem is that your regulators are close on the world's worst. That's let the carriers do almost whatever they want. The first step to fixing this is to stop making excuses an see the problem for what it is.
I have personally purchased a 10 Mbps connection. I understand that there is network overhead, line noise, packet loss, whatever... But I have never, ever seen any more than 3 Mbps.
That's because you're on ADSL and it's a crappy technology unless you're sitting on a short high-quality line. And there's nothing the ISP can do about it short of putting in a new line; it's a physical restriction. Would you want to pay for that yourself? If not, why should other people buy it as a gift for you?
If you go read the ISP's ads carefully, I bet you'll see the weasel words "up to" before that bandwidth measure. Your best move is to consider trading down to a cheaper and slower connection; the loss of bandwidth you never had shouldn't be too much of a concern, and then you'll at least have more money in your pocket. (OK, imperfect but beats arguing with physics.)
Just put all your instructions in a row and execute them one after another. As long as you make sure that you only write the instructions that you want to execute instead of any of this conditional or looping rubbish, you'll be able to execute them directly without any jumps.
You might think I'm joking, but some people really do write their code exactly like this. They are, of course, utterly mad. (IIRC, they were physicists.)
No. Most manpages suck, especially on Linux. Sorry, but it's true. BSD manpages are usually better because they've a legacy of being better (there's a history of them having had a good tech writer spruce them up sometime way back, and that's encouraged them to stay good) whereas too many Linux utils and syscalls are poorly documented (GNU utils because they think you should be using texinfo, Linux syscalls because there's a tendency to say RTFS).
They could be better. Making them better needs effort, and it needs someone other than the original developer to help (because the developer is usually too close to understand what needs to be documented, or at least that's how it is for me). I also advise not worrying about the format of the documentation; plain old text is hugely better than nothing...
Slashdot Mirror
You mean the same moderating system that hasn't given me mod points in 4 or 5 years?
The slashdot system seems to be relatively hard on people who post one-liner smartass comments all the time. If we look back through your recent history then we don't see a lot that is likely to attract the karma-positive moderations. I suspect it also helps if you include a little context with <quote>s of what you're talking about. Otherwise it is too easy for people doing metamodding to not understand what you're talking about (no, you don't need to quote the whole lot. Just the relevant sentence or two).
The only problem is that a number of shared hosts don't allow for pdo with mysql (or postgres). For example, I use FatCow, and they only have PDO enabled for sqlite, which is the php default setting. I've asked them to change this during their quarterly suggestion review, but they have yet to enable it.
That sounds to me like it is worth considering relocating your business to another facility that does support PDO with mysql and/or postgres. Why put up with bad service when there's someone else who'll be willing to do things properly so you can avoid the pain points?
As long as there is money to be made, viruses will be made. Or power (intelligency agencies).
Money and asshole-dom are the keys to why malware is created. Money is what allows the asses to keep on doing it rather than going off and doing something more worthwhile to earn a living. Only assholes make malware in the first place (yes, I've seen people claiming to be non-asses who are making "non-evil" malware, but I don't trust them and consider them to be part of the group of people I don't want on this system at all anyway).
For the most part, intelligence agencies prefer to watch who you're talking to what you're saying, since traffic analysis is easier than cracking. They don't trust that they'll be able to break into your machine undetected, so they don't rely on being able to do so (well, except in special cases which I'd bet you don't fall into, unless you're really a terrorist).
The USA is the best nation in everything.
Especially including self-delusion!
You seriously believe that Big Brother watches you from a .mil hostname?
Why not? They're arrogant enough to not cover their tracks more thoroughly (after all, it's not like most people would have noticed) and you're dismissive enough. Playing right into their hands.
[Eritrea is] relatively pro-Western
Maybe so, but it does depend on what your baseline is. They've got a bunch of fascists in charge who hate their (much larger) neighbors more than they hate us. They have no oil to speak of though, nor a navy worth the name to cause trouble in the Red Sea, so we ignore them.
What is a "biometric visual scan of their face"? A photograph?
Every country does that.
No, they don't. Yet.
You use different words but the problem is still the same. I'll speak in generic terms.
What happens when the system is compromised and someone else can identify as me? How do I again secure my identity? What do I change? How do I change it?
What happens if someone breaks into the database and swaps around the biometric parts of the records for politicians and known terrorists?
It doesn't seem like any of the ARM based procs support IEEE 754r.
For a long time, they didn't support straight IEEE 754 either, and did all float handling in software. (Don't know if that's changed. At the time I was involved in circuit-level simulation of ARM CPUs, but that was ages ago.)
Which means JUST CHECK IT ONCE at the start of the queue. The 2nd check is completely and utterly pointless. Hell I once realised I'd been showing them the wrong boarding pass, it was only when I went to get on the plane that they pointed it out.
At my airport, they check boarding passes against a computerized list of people who are allowed in the secured area (and have done for a few years now). This is at the start of the line, and there are no further checks on the boarding pass until you're actually going through the gate, presumably then a check to see if you're getting on the right plane. On the other hand, this isn't in the US. (The UK has had restrictive security at airports for many years; 9/11 made little difference here in practice.)
Passports aren't checked on exit until you're actually boarding an international flight, and that looks like a check to see that the name matches the boarding pass and the picture matches the person. I guess that allows those deep checks that they do want to do to be carried out between the time when you buy your ticket and when you get your boarding pass.
What if I need stupid served after 11?
That's what slashdot trolls are for.
If you could hit the back button and instantly be back on the page you were looking at and at the same position of that page, with no reloading and reflowing to mess you up, you wouldn't need tabs to load a quick check of a link. Refresh is a single key-combo away if you need it. It shouldn't be the default. You shouldn't need tabs just to look at three or four links in the middle of a page one at a time.
You seem to be assuming that the only use for tabs is for doing quick checking of links. That's definitely not the only use I put them to (I've currently got 13 long-lived pages open on different tabs and I browse them asynchronously relative to each other). Your assumption only holds for a subset of browsing behavior.
If the code, documentation, and specs disagree, all you know for certain is that for the last 10 years, the code has been running in production this way because that was the last time it was compiled. That doesn't make it right, but you had better find someone to explain it.
If code, docs and specs all disagree then you've got problems. Doubly so if the code doesn't appear to correlate at all with the behavior of the deployed program. I've seen that (someone had patched the binary for unknown reasons...)
When you're working with componentized software, it's more important to be spec driven. This is because the consumers of the code usually work according to the spec (most programmers aren't too keen on having to read someone else's source just to find out how to use it). In those cases, it's also easy to have a feature that is only rarely used and which doesn't work (e.g., by crashing, a clearly undesirable situation). If that happens, you're stuck with working out whether this was a problem of the spec or the implementation or the documentation (i.e., if the component was just called wrong). Sometimes life's like that.
Of course, even better than the spec is having the design theory of the code. That's because it allows you to know how the original author was envisaging evolving things, and it lets you know which parts are just code that was put in to make it work and so can be improved/fixed without trouble. With the design theory, you can even re-derive the spec from first principles. But yes, it's often (even usually) missing, as most junior programmers just don't grasp why it is important and so never write it down.
The fact that a FET is called a FET doesn't mean it is a transistor, any more than the Democratic People's Republic of Korea is democratic, for the people, or a republic.
Ah, you come from the school of redefinition, so you're trying to change the meaning of the word "transistor" to mean what will support your foolish argument. Yes, there are two types of transistor, each with different characteristics that orient towards particular applications (e.g., high-power for BJT, digital logic for FET) but to define only one of them as a "true" transistor just speaks of your ignorance. You must be a sound engineer?
Next up given how weak your argument is, you'll be raising your voice or writing in capitals.
"Perl is more than just the vagaries of syntax. Perl is philosophy; Perl is custom; Perl is architectual edifice; Perl is community."
And Perl6 is a jump over the shark.
I've seen snippets of Perl6 and it does indeed look rather different from previous versions of Perl. Does it stand a good a chance of running lots of existing perl scripts without nasty interop goop? If not, it's really another language and should not hang off Perl's coattails. Call it "Rakudo" instead (after all, that name's used right now) and let it find its own way in the world of languages. If instead they'd stuck to being, say, 95% compatible with existing perl scripts then, while it would have constrained their creativity, it would mean they'd be able to pick up on the wealth of CPAN for little extra effort.
And this is relevant to 99.9% of the software out there how?
It isn't. Now. But if the code is inherited from the "olden days", then those stupid restrictions did matter back then. (I remember Ultrix. How I hated how Ultrix carried out linking. The old Linux a.out system was much nicer, despite being awful.)
Well, let's see... when it's the person who hired you that isn't "fully familiar with arrays", because he's the one that started the company, maybe you can "do the math".... ;)
In that case "the math" says to me that it is time to look for another job where the owner won't be sabotaging you with abject stupidity. Just sayin'.
the only correct documentation is the code itself
Sounds like you've not done very much maintenance programming. The problem is that the code is often wrong too. So now you've got to figure out what it was supposed to do originally (good luck, the developer's left the company under a cloud and didn't leave a forwarding address) and also what all the clients of the code are expecting it to do (typically at variance with what the code does and what it is supposed to do). At that point, reading the code doesn't help very much. Yes, you know that it is setting certain flags in an indirectly-accessed context by performing a calculation and then XORing the result, but do you know if they are the right flags? Were they ever correct? Did the meaning change from then and the calculation not get updated? Who knows?
External documentation should cover the high-level design of the system; the principles upon which it is all founded. That doesn't change very fast (total replacement of the basic data structure of a program is hard, and rarely done). Comments on the code (plus sensible naming of functions, arguments and variables) should cover how the big picture fits to the local view of what is going on. It's rare indeed that you need blow-by-blow comments on each line of the function; that's when reading the damn code itself ought to suffice. (The code itself only ever says "how"; it never says "why", and only says "who" and "when" in the most cryptic fashion. For maintenance, "why" is the key question.) An objective spec (which can be external, but which most certainly isn't the code) makes it easier to say whether the code is right or wrong, and if wrong, how it can be fixed or improved without causing difficulties. A spec does not need to be long either; lots of functions are characterized by just a line. Refusing to comment at all is just ridiculous and malicious.
These can be comments in code, but SVN (or any SCM) commit comments are also extremely useful for this.
Those tell you who, which is useful for getting back at them when you find that something "clever" was deposited in code you maintain. I know of devs who always commit with a message "fix the bug". Thankfully, they use genuinely good commenting practices or I'd be forced to hunt them down and put them out of my misery.
The advantage of comments is that they're right there in the code when you're looking at it. Commit log messages typically need an extra step to retrieve (especially when you've got a complex and old file, when identifying who committed the core of the code you're looking at, and not just the last change to it).
Also have you see seen the population density and land mass of Europe compared to NA?
You're just making excuses there. Finland has about half the population density of the US, so it would have to have much worse coverage outside the main cities? Norway has about 40% of the density, so it would be even worse still? Well, no. About all that you can really say is that with the US, the national carriers are really big (and they don't offer particularly great coverage anyway in the real backwoods parts, but so?) If you're saying that they have to screw their customers over just because there's a lot of people in the US, then you're just being a shill (paid or unpaid, I know not which) for the carriers.
The real problem is that your regulators are close on the world's worst. That's let the carriers do almost whatever they want. The first step to fixing this is to stop making excuses an see the problem for what it is.
I have personally purchased a 10 Mbps connection. I understand that there is network overhead, line noise, packet loss, whatever... But I have never, ever seen any more than 3 Mbps.
That's because you're on ADSL and it's a crappy technology unless you're sitting on a short high-quality line. And there's nothing the ISP can do about it short of putting in a new line; it's a physical restriction. Would you want to pay for that yourself? If not, why should other people buy it as a gift for you?
If you go read the ISP's ads carefully, I bet you'll see the weasel words "up to" before that bandwidth measure. Your best move is to consider trading down to a cheaper and slower connection; the loss of bandwidth you never had shouldn't be too much of a concern, and then you'll at least have more money in your pocket. (OK, imperfect but beats arguing with physics.)
you can write assembly without JMP? impressive.
Just put all your instructions in a row and execute them one after another. As long as you make sure that you only write the instructions that you want to execute instead of any of this conditional or looping rubbish, you'll be able to execute them directly without any jumps.
You might think I'm joking, but some people really do write their code exactly like this. They are, of course, utterly mad. (IIRC, they were physicists.)
The day Alex announced this was the day I finally stopped reading the DailyWTF.
They've had a couple of good ones this week.
I refill my 4-color printer with Blood, Sweat and Tears (4th bodily fluid "redacted" as this is a family site).
Bile isn't that disgusting in itself.
Manpages suck for the average programmer.
No. Most manpages suck, especially on Linux. Sorry, but it's true. BSD manpages are usually better because they've a legacy of being better (there's a history of them having had a good tech writer spruce them up sometime way back, and that's encouraged them to stay good) whereas too many Linux utils and syscalls are poorly documented (GNU utils because they think you should be using texinfo, Linux syscalls because there's a tendency to say RTFS).
They could be better. Making them better needs effort, and it needs someone other than the original developer to help (because the developer is usually too close to understand what needs to be documented, or at least that's how it is for me). I also advise not worrying about the format of the documentation; plain old text is hugely better than nothing...