Expand the pool of candidates applying for the job.
Did they not let women apply before?
There are other ways of expanding the pool of candidates. Perhaps they'd been advertising their vacant positions in media that were largely read by men?
Try reading the whole thing. Vegans were covered with sugar and bone char.
It's lucky you can't get vegan sugar (or indeed just not eat sugar), or else that point would be invalid too;-)
Not to mention the fact that your argument makes no sense - if some people believe that all killing of animals is wrong (I don't), the fact that they don't manage to live up to that ideal doesn't necessarily make them wrong. They may *be* wrong, but you'd need a better argument to demonstrate it.
That assumes that each individual package was independent and random.
A single unlucky or freak event could affect multiple samples (for example if a sack holding 6 atheist packages gets lost or damaged).
You make a good point - but given that two otherwise-identical packages were sent to each address at the same time, what are the chances that all the "atheist" packages would be put in one sack, and all the plain ones in another? Isn't the more plausible hypothesis that either packages would be assigned to sacks (/planes/trucks/etc) at random, or that ones going to the same address would have a much higher probability of ending up together? In either case, the probability of the sort of bias you mention is much reduced.
And that is why the progress bar should represent progress of the task, not remaining time. The correct way is to show progress in the bar (as in percent of the total task), and a text label with the estimated time to completion below. The label can change in any direction. The progress bar (if the progress is measured properly) can only go forward.
The trouble is that, very often, the amount of work to do is not known up front - for example, when copying a large directory hierarchy, there's no way to know how many files will be in the next subdirectory traversed (without scanning the directories beforehand, which may add substantially to the time taken). As more information is discovered (say, reading a new subdirectory and discovering that there are a lot more files than previously estimated), the best estimate of the percentage of the task that is complete has genuinely gone down. The only options available are to lie about the estimate (displaying it as larger than is now believed to be true), or to make the progress bar go backwards (clearly undesirable for several reasons).
Do you know what a corporation is? That it is a different concept than "company"[...]?
In fairness, the definitions of those words (and whether they refer to the same thing) depends on jurisdiction. But you're right that many charities are incorporated.
It's nice to be able to know what the name of a file is before deleting it - it may give some idea about whether it should be kept or not.
2. Putting non-ASCII characters in filenames is an even worse idea than putting spaces in filenames. Don't do it, and you won't have problems.
I don't do it. The users on systems I (hypothetically) maintain may not be so considerate. Especially if their first language is written in a different alphabet.
1. You should have consulted a table of Linux-compatible keyboards before you bought your keyboard.
Or perhaps consult a Linux compatibility table before deciding to be born into a country with an unsupported language? Or are you suggesting that everyone should keep two keyboards, one for the language they use all the time, and one for Linux console use? (In practice it wouldn't help either, because Linux supports virtually all keyboards in desktop environments, so your compatibility table would likely say "yes" even without full console support.)
Is it actually impossible to type in umlauts? Or does the console simply not show them correctly?
From memory, it can actually cope with both typing umlauts and displaying them - but the suggestion is that there are other internationalisation cases not handled so well.
Besides, doesn't ext2/3 reserve some disk space for the root by default? 5% if memory serves. Enough to get userspace - even X - running, at the very least.
It does do that, but in practice it doesn't always help: if a daemon running as root has issues that mean it writes lots of logs, that can fill the disk completely - and you don't necessarily want to delete the logs since you may need them for further investigation, so finding something else may be necessary.
Yes, I know, but the claim is that its keyboard handling is less than perfect. I don't know the details of that; I was merely making the point that "just use ASCII" isn't enough to mean you don't need to worry about keyboard mappings.
"handles keyboards badly": Does it drop keystrokes? If it doesn't do that, there's absolutely no rational basis for this complaint. Maybe baby wants his arrow keys, or non-ASCII character set? Screw that. This is a console. Use vi commands like a grownup.
Maybe the user wants to get the ">" symbol on pressing the ">" key. Which is different on different keyboard layouts. Doesn't seem too unreasonable...
And you don't need your umlauts and accents. The commands are all composed of ASCII characters.
... but the filenames aren't. When you're trying to free up vital disk space by deleting hügë_fïlë.jpg, wouldn't it be handy to be able to type its filename?
Here's the Finnish constitution, translated into English. I haven't read it all, but it doesn't seem to say a lot about freedom of speech other than in the context of the parliament.
Actually, $foo[3] is the *fourth* element of @foo. You count the array elements starting at 0, just like in C and assembler.
Not necessarily: it depends on the value of the $[ variable. Which isn't actually a variable. (Yes, Perl variable names can consist purely of punctuation. Yes, there are things that look like variables but actually aren't. Yes, you can override the index from which arrays are numbered.)
Turning this into a game with the hope of making money is cynical and tasteless.
Maybe, but totally protected under the 1st amendment.
True, but this isn't about Congress passing a law to restrict speech - it's about one company deciding not to sell a third party's product...
People and companies churn out tasteless crap all day. Perhaps they should all be censored. Good thing I don't have to buy Apple's crap.
Exactly - those (myself included) who are uncomfortable with either Apple's policies, or the general stranglehold they like to maintain on their ecosystem, are free to buy other stuff:-)
...the game ran afoul of the guidelines for including Japanese flags in a WWII naval sim.
So if Godzilla were to attack New York would Apple deny a sim after the fact because it was unfair to monsters?
The policy in question was about games depicting entities that are real. Despite what Stephen King and Dr Who may have you believe, most adults consider that monsters are not real:-)
and if a nurse who should be able to tell whether or not she was sick notices these symptoms and removes herself from those she could potentially contaminate is there that big of a difference? (honest question)
If (s)he can notice them in time, and if (s)he can safely remove him/herself from the vicinity of patients immediately without leaving them with insufficient care - then maybe.
Or what if a nurse maintained all the proper hygiene requirements that are already in place? Because the flu is definitely not the only airborne disease a nurse would come into contact with on a day to day basis.
That's true, of course, but it is a very common disease, that spreads easily and can be very harmful/dangerous to those whose health is already compromised in some way, so putting mitigation measures in place makes a lot of sense.
Is the difference in rate of infection big enough to warrant them firing nurses?
Now that is a different question entirely - putting infection control measures in place is common sense, but whether this particular action is proportionate is a lot more open to debate:)
Unless you can explain how the vaccinating the nurse will keep the flu infected patient from coughing and sneezing, those droplets will keep transmitting the virus.
If the vaccine stops the nurse contracting the flu, then it stops the nurse coughing and sneezing, which reduces the risk of transmission. You're right that there are other modes of transmission than patient->nurse->patient, and vectors other than airborne water droplets, but it makes sense that removing one significant transmission path will have an effect on the rate of transmission, right?
I'm curious as to how the vaccine in question prevents coughing and sneezing, though. I'm not familiar with vaccines having that effect.
The vaccine stops you getting (certain strains of) flu. The flu virus causes coughing and sneezing. Therefore, by preventing you getting the flu, it stops the coughs and sneezes that the flu would otherwise have given you. Is that really so hard to understand?
Is Dr. Orient wrong? Is there evidence that immunized workers are less likely to transmit the virus.
'Flu is transmitted (among other routes) by airborne water droplets. It also causes the sufferer to cough and sneeze (thus spraying such droplets).
It's hardly conclusive, but based on those facts I find it a little hard to believe that the vaccine (which will prevent the coughing and sneezing) has no effect on transmission...
If you're immediatelly going to break it (step 3), why bother with marking it obsolete (step 1)?
In order to ensure that step 2 doesn't take an infinite amount of time (by ensuring that, while you're finding places where the function is called and removing them, someone else isn't concurrently adding new calls...).
If this is your goal, then you should just practice code-review of every commit and that'll achieve the same goal.
Only if every single developer that might look at the code reviews every single line. That doesn't scale beyond a small team.
In general it's best to delete unwanted code, but in some cases (e.g. where the code being changed is related to working a bug in a third-party's software, so it may not be possible to tell what the "right" code is apart from by experimentation) it can be useful to leave the deleted code around for a while to notify anyone fixing bugs in that area - provided a suitable comment explains why the code has been commented out. Leaving the code surrounded by "/*...*/", but with no explanation, is not helpful...
H-1Bs are like gold to any company because morale is not an issue, they can be paid scraps, and payroll taxes don't apply to them.
Is that true? I admit I know very little about this, but I thought they largely had to pay the same tax as anyone else. Certainly that's what I understood from here - do you have a link that explains more clearly?
Comments don't help as much as people think they do. Unless you know the coder, comments cannot be trusted and you will normally need to go by what the code says far more than what the comments say.
Sure, you can't 100% trust comments, but that doesn't mean they're not useful. For cases like your "save starts here" example, even if there's a chance the comment is wrong, it provides a good place to start looking - if the comment turns out to be wrong, sure, I'll have to search the whole file, but without comments I'll always have to do so...
Slashdot Mirror
Expand the pool of candidates applying for the job.
Did they not let women apply before?
There are other ways of expanding the pool of candidates. Perhaps they'd been advertising their vacant positions in media that were largely read by men?
Try reading the whole thing. Vegans were covered with sugar and bone char.
It's lucky you can't get vegan sugar (or indeed just not eat sugar), or else that point would be invalid too ;-)
Not to mention the fact that your argument makes no sense - if some people believe that all killing of animals is wrong (I don't), the fact that they don't manage to live up to that ideal doesn't necessarily make them wrong. They may *be* wrong, but you'd need a better argument to demonstrate it.
Read the rest of the comment, numbnuts.
Vegans are covered with bonechar and sugar. I guess to make it crystal clear I should have said "For vegetarians egg....."
My apologies for replying to what you actually wrote.
Are you a vegan? Even if you are you likely benefit from the deaths of animals. Egg laying chickens are killed once their useful lives are over
Presumably that's why vegans don't eat eggs.
That assumes that each individual package was independent and random.
A single unlucky or freak event could affect multiple samples (for example if a sack holding 6 atheist packages gets lost or damaged).
You make a good point - but given that two otherwise-identical packages were sent to each address at the same time, what are the chances that all the "atheist" packages would be put in one sack, and all the plain ones in another? Isn't the more plausible hypothesis that either packages would be assigned to sacks (/planes/trucks/etc) at random, or that ones going to the same address would have a much higher probability of ending up together? In either case, the probability of the sort of bias you mention is much reduced.
And that is why the progress bar should represent progress of the task, not remaining time. The correct way is to show progress in the bar (as in percent of the total task), and a text label with the estimated time to completion below. The label can change in any direction. The progress bar (if the progress is measured properly) can only go forward.
The trouble is that, very often, the amount of work to do is not known up front - for example, when copying a large directory hierarchy, there's no way to know how many files will be in the next subdirectory traversed (without scanning the directories beforehand, which may add substantially to the time taken). As more information is discovered (say, reading a new subdirectory and discovering that there are a lot more files than previously estimated), the best estimate of the percentage of the task that is complete has genuinely gone down. The only options available are to lie about the estimate (displaying it as larger than is now believed to be true), or to make the progress bar go backwards (clearly undesirable for several reasons).
The only problem I would really have with handing in hard copies is that nobody uses floppies anymore,
Floppies don't really count as hard copy...
Do you know what a corporation is? That it is a different concept than "company"[...]?
In fairness, the definitions of those words (and whether they refer to the same thing) depends on jurisdiction. But you're right that many charities are incorporated.
3. This is why your shell has wildcards.
It's nice to be able to know what the name of a file is before deleting it - it may give some idea about whether it should be kept or not.
2. Putting non-ASCII characters in filenames is an even worse idea than putting spaces in filenames. Don't do it, and you won't have problems.
I don't do it. The users on systems I (hypothetically) maintain may not be so considerate. Especially if their first language is written in a different alphabet.
1. You should have consulted a table of Linux-compatible keyboards before you bought your keyboard.
Or perhaps consult a Linux compatibility table before deciding to be born into a country with an unsupported language? Or are you suggesting that everyone should keep two keyboards, one for the language they use all the time, and one for Linux console use? (In practice it wouldn't help either, because Linux supports virtually all keyboards in desktop environments, so your compatibility table would likely say "yes" even without full console support.)
Is it actually impossible to type in umlauts? Or does the console simply not show them correctly?
From memory, it can actually cope with both typing umlauts and displaying them - but the suggestion is that there are other internationalisation cases not handled so well.
Besides, doesn't ext2/3 reserve some disk space for the root by default? 5% if memory serves. Enough to get userspace - even X - running, at the very least.
It does do that, but in practice it doesn't always help: if a daemon running as root has issues that mean it writes lots of logs, that can fill the disk completely - and you don't necessarily want to delete the logs since you may need them for further investigation, so finding something else may be necessary.
Yes, I know, but the claim is that its keyboard handling is less than perfect. I don't know the details of that; I was merely making the point that "just use ASCII" isn't enough to mean you don't need to worry about keyboard mappings.
"handles keyboards badly": Does it drop keystrokes? If it doesn't do that, there's absolutely no rational basis for this complaint. Maybe baby wants his arrow keys, or non-ASCII character set? Screw that. This is a console. Use vi commands like a grownup.
Maybe the user wants to get the ">" symbol on pressing the ">" key. Which is different on different keyboard layouts. Doesn't seem too unreasonable...
And you don't need your umlauts and accents. The commands are all composed of ASCII characters.
... but the filenames aren't. When you're trying to free up vital disk space by deleting hügë_fïlë.jpg, wouldn't it be handy to be able to type its filename?
Here's the Finnish constitution, translated into English. I haven't read it all, but it doesn't seem to say a lot about freedom of speech other than in the context of the parliament.
Not in a modern release of Perl (5.16).
It works there too. There's a warning about it being deprecated, but it still works.
Yes, that's why I wrote "the element 3", not "the third element".
Yes, but unfortunately you let one "third" slip through the net:
In Perl, you have to write $foo[3] because the third element of the array is a scalar.
I'm sure $[ was equal to one for that sentence, though ;-)
Actually, $foo[3] is the *fourth* element of @foo. You count the array elements starting at 0, just like in C and assembler.
Not necessarily: it depends on the value of the $[ variable. Which isn't actually a variable. (Yes, Perl variable names can consist purely of punctuation. Yes, there are things that look like variables but actually aren't. Yes, you can override the index from which arrays are numbered.)
Turning this into a game with the hope of making money is cynical and tasteless.
Maybe, but totally protected under the 1st amendment.
True, but this isn't about Congress passing a law to restrict speech - it's about one company deciding not to sell a third party's product...
People and companies churn out tasteless crap all day. Perhaps they should all be censored. Good thing I don't have to buy Apple's crap.
Exactly - those (myself included) who are uncomfortable with either Apple's policies, or the general stranglehold they like to maintain on their ecosystem, are free to buy other stuff :-)
...the game ran afoul of the guidelines for including Japanese flags in a WWII naval sim.
So if Godzilla were to attack New York would Apple deny a sim after the fact because it was unfair to monsters?
The policy in question was about games depicting entities that are real. Despite what Stephen King and Dr Who may have you believe, most adults consider that monsters are not real :-)
and if a nurse who should be able to tell whether or not she was sick notices these symptoms and removes herself from those she could potentially contaminate is there that big of a difference? (honest question)
If (s)he can notice them in time, and if (s)he can safely remove him/herself from the vicinity of patients immediately without leaving them with insufficient care - then maybe.
Or what if a nurse maintained all the proper hygiene requirements that are already in place? Because the flu is definitely not the only airborne disease a nurse would come into contact with on a day to day basis.
That's true, of course, but it is a very common disease, that spreads easily and can be very harmful/dangerous to those whose health is already compromised in some way, so putting mitigation measures in place makes a lot of sense.
Is the difference in rate of infection big enough to warrant them firing nurses?
Now that is a different question entirely - putting infection control measures in place is common sense, but whether this particular action is proportionate is a lot more open to debate :)
Unless you can explain how the vaccinating the nurse will keep the flu infected patient from coughing and sneezing, those droplets will keep transmitting the virus.
If the vaccine stops the nurse contracting the flu, then it stops the nurse coughing and sneezing, which reduces the risk of transmission. You're right that there are other modes of transmission than patient->nurse->patient, and vectors other than airborne water droplets, but it makes sense that removing one significant transmission path will have an effect on the rate of transmission, right?
I'm curious as to how the vaccine in question prevents coughing and sneezing, though. I'm not familiar with vaccines having that effect.
The vaccine stops you getting (certain strains of) flu. The flu virus causes coughing and sneezing. Therefore, by preventing you getting the flu, it stops the coughs and sneezes that the flu would otherwise have given you. Is that really so hard to understand?
Is Dr. Orient wrong? Is there evidence that immunized workers are less likely to transmit the virus.
'Flu is transmitted (among other routes) by airborne water droplets. It also causes the sufferer to cough and sneeze (thus spraying such droplets).
It's hardly conclusive, but based on those facts I find it a little hard to believe that the vaccine (which will prevent the coughing and sneezing) has no effect on transmission...
If you're immediatelly going to break it (step 3), why bother with marking it obsolete (step 1)?
In order to ensure that step 2 doesn't take an infinite amount of time (by ensuring that, while you're finding places where the function is called and removing them, someone else isn't concurrently adding new calls...).
If this is your goal, then you should just practice code-review of every commit and that'll achieve the same goal.
Only if every single developer that might look at the code reviews every single line. That doesn't scale beyond a small team.
In general it's best to delete unwanted code, but in some cases (e.g. where the code being changed is related to working a bug in a third-party's software, so it may not be possible to tell what the "right" code is apart from by experimentation) it can be useful to leave the deleted code around for a while to notify anyone fixing bugs in that area - provided a suitable comment explains why the code has been commented out. Leaving the code surrounded by "/*...*/", but with no explanation, is not helpful...
H-1Bs are like gold to any company because morale is not an issue, they can be paid scraps, and payroll taxes don't apply to them.
Is that true? I admit I know very little about this, but I thought they largely had to pay the same tax as anyone else. Certainly that's what I understood from here - do you have a link that explains more clearly?
Comments don't help as much as people think they do. Unless you know the coder, comments cannot be trusted and you will normally need to go by what the code says far more than what the comments say.
Sure, you can't 100% trust comments, but that doesn't mean they're not useful. For cases like your "save starts here" example, even if there's a chance the comment is wrong, it provides a good place to start looking - if the comment turns out to be wrong, sure, I'll have to search the whole file, but without comments I'll always have to do so...