|
|
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
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.
"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?
Yes, you can override the index from which arrays are numbered.
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.
Actually, $foo[3] is the *fourth* element of @foo.
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
Q: What do you say to a Puerto Rican in a three-piece suit? A: Will the defendant please rise?