It depends on the level of scientist. Where I work, only the higher level research positions make more money than most public school teachers in the state.
People don't want to work in high schools because... high school students. Here in Ohio, you need to get the first two years of BS-level (not BA-level) major coursework as prerequisites for the masters you need to teach a high school science. Mind you, that alone doesn't make you a scientist, but you should have a good idea of what is involved at that point.
That being said, with the original topic of the news item, it says "scientific flaws", not just disagreements. The vast majority of creationist criticisms against evolution, for example, are non-scientific (or can be easily shown to violate/ignore accepted principles and facts).
A trick someone I know did, was have a few entries scattered about the robots.txt file, some with nothing linked to them. After going to that link, the server is updated to send anyone from that IP address a 404 response on all requests.
I wonder if something similar could be done. It caught quite a few bots.
Or ignore it. I'd think it'd be fairly trivial to ignore that header, especially if there is a least one country that doesn't legally require it to be honored (and even without that, they'll probably still ignore it in countries where it is illegal).
This post is proprietary and confidential. By accepting it, Slashdot agrees to not publish it to any third parties without my explicit permission. Violations of this contract will result in Commander Taco being legally bound to turn into a tunicate for not less than 36 hour greater than the duration at which this post is made available to any unauthorized third parties.
Yes, but that problem has been trivially solved for a LONG time (access to the physical hardware requires getting through a lock that need multiple people to unlock it.)
You would then argue that locks can be picked, etc. And I can then reply with monitoring the access areas - the person would have to be a fast lock pick and hacker to get in and do any harm, even then the machine could be quarantined.
Nobody is dumb enough to think there is no cost associated with these measures, the question is - is the extra security worth it. Unless the system is under your authority, you can't answer that question.
I wasn't suggesting they were simple - but some times worthwhile things are not simple.
Or rather, a file system attribute 'validators', where the file would require a number of validators for any write or modification to take place.
As I said, it's only a minimum sub-set. Many things could be handled by one use (example, if I were admin, I could change any non-admin password, but would need validation for admin passwords). A secondary backup would be needed, yes, but often times not needed.
That was a quick type up, and that looks a bit like a typo - the idea is, that even as root, the really secure stuff requires validation from other accounts.
I disagree. You can instead trust some/people/ with proper checks and balances. This can, in some situations, reduce the risk (for example, if more than one is required for approval of certain things)
Some times it's a matter of you really can't/shouldn't trust ANYONE but you have no choice. In these cases, a validating/verifying approach can be helpful.
Agreed, catastrophes are a huge issue. An additional one I know of is some people with no ability to reciprocate respect, who could one day (or already have) administrative access to systems.
These people need checks and balances. If they decide to quit, they would likely do something slightly harmful for "fun" unless someone got to their account first. Most likely the only safe way to let them go would be to literally "terminate" them.
another idea for this, though it involves a bit of work per admin - it's nice to keep a separate login and sudo-to-root password.
Create the normal account (i.e. bio) and the admin account (bio-admin) for a given user. The normal user (bio) can only sudo into that user's admin account (bio-admin), and the admin account has sudo access to root. Set up a couple of shell scripts. Move 'sudo' to 'sudo_base'. Create a sudo script which is something like
#!/bin/sh
sudo_base -u "${USER}-admin" sudo_base $@
then a sudo-passwd scritp:
#!/bin/sh
sudo_base -u "${USER}-admin" sudo_base passwd
And the "non-priv" accounts only have sudo access to 'sudo_base' and 'passwd', and only when switching to their 'admin' subaccounts.
A subset of administrative applications requiring multiple administrators may not be such a bad compromise.
ex: * change root password (or password to any "wheel" account) - requires multiple administrators to enter the same passwords *su/sudo'ing to a "wheel" account, or changing said account's privileges, requires the authorization of at least one other wheel'ed user. * Alterning an active network interface, shutting down, and restarting requires authorization by other administrative users.
Stuff like that, which are things that shouldn't be done often, anyway, and could allow one admin to take over the whole system, seem like good candidates for multiple-approvals. Everything else could be left alone.
The approval process is basically - the root users needs to take the action, and then 2+ non-root (but wheel) users must approve it.
I'm using 'wheel' as that is the group in FreeBSD that is typically allowed access to sudo/su. Not sure how other systems typically work.
There's this thing called 'modular programming'. You program things in coherent chunks. For example, you could program a good bit of the lower-level UI level stuff in a chunk (window/panel handling, for example) to handle any system. Now later, you could say "Wait, we could make this faster with Accelerated Hardware X) and then make a second module, that can be accessed in the same way, but uses Accelerated Hardware X. Now, at load time (or install time, or configuration time), it could spend a half dozen cycles to determine if Hardware X is available, and run that module or the default based one the result.
No support is lost, but some platforms will perform better.
given your last comment - I think pre-defined hardware such as AMD/Intel desktop chips will always be faster than FPGA for a pre-specified set of individual operations. It's only when you get to operation combinations not defined at manufacture time, but used frequently, that FPGA has an advantage.
The current CPU design will stay for most of the work, and an FPGA attachment would handle the specialty work that isn't needed most of the time, and can be dropped.
This issue is reprogramming time and muti-threaded/multiprocessing apps. If you have five applications requiring different FPGA setup, but only two FPGA cores, time sharing could be quite painful.
Slashdot Mirror
It depends on the level of scientist. Where I work, only the higher level research positions make more money than most public school teachers in the state.
People don't want to work in high schools because... high school students. Here in Ohio, you need to get the first two years of BS-level (not BA-level) major coursework as prerequisites for the masters you need to teach a high school science. Mind you, that alone doesn't make you a scientist, but you should have a good idea of what is involved at that point.
That being said, with the original topic of the news item, it says "scientific flaws", not just disagreements. The vast majority of creationist criticisms against evolution, for example, are non-scientific (or can be easily shown to violate/ignore accepted principles and facts).
The tend to show up once or twice a month.
Don't forget the southern baptists claiming there are hidden sex messages in the moon landing videos!
Well, this will make you feel even more inadequate.
I once got a spam telling me that a real cyborg turtle could be mine!
To this day, I'm kicking myself for not taking them up on that offer.
Actually, you may be on to something
A trick someone I know did, was have a few entries scattered about the robots.txt file, some with nothing linked to them. After going to that link, the server is updated to send anyone from that IP address a 404 response on all requests.
I wonder if something similar could be done. It caught quite a few bots.
Of two dozen or so people I've heard from (yeah, small group), you are #3 for whom that has worked.
Yes, because the criminal organizations often behind the worst of this stuff care *so much* about US sanctions against the country they are in.
Or ignore it. I'd think it'd be fairly trivial to ignore that header, especially if there is a least one country that doesn't legally require it to be honored (and even without that, they'll probably still ignore it in countries where it is illegal).
They won't fight it, they laugh at it.
Who was s/he sticking up for? Looks like the GP was suggesting that there is no evidence that Slashdot knows better than to feed the trolls.
This post is proprietary and confidential. By accepting it, Slashdot agrees to not publish it to any third parties without my explicit permission. Violations of this contract will result in Commander Taco being legally bound to turn into a tunicate for not less than 36 hour greater than the duration at which this post is made available to any unauthorized third parties.
Fascism? That's a bit of a strech. Ignorance less, so, but then again, every country is full of ignorance. Need proof for yours? Look in a mirror.
yeah. but not surprising. Yey trailer parks, the bring out the best of this wonderful country...
Seriously, how the hell can it be treason if he isn't a US citizen (or otherwise legal resident)?
Yes, but that problem has been trivially solved for a LONG time (access to the physical hardware requires getting through a lock that need multiple people to unlock it.)
You would then argue that locks can be picked, etc. And I can then reply with monitoring the access areas - the person would have to be a fast lock pick and hacker to get in and do any harm, even then the machine could be quarantined.
Nobody is dumb enough to think there is no cost associated with these measures, the question is - is the extra security worth it. Unless the system is under your authority, you can't answer that question.
I wasn't suggesting they were simple - but some times worthwhile things are not simple.
Or rather, a file system attribute 'validators', where the file would require a number of validators for any write or modification to take place.
As I said, it's only a minimum sub-set. Many things could be handled by one use (example, if I were admin, I could change any non-admin password, but would need validation for admin passwords). A secondary backup would be needed, yes, but often times not needed.
That was a quick type up, and that looks a bit like a typo - the idea is, that even as root, the really secure stuff requires validation from other accounts.
I disagree. You can instead trust some /people/ with proper checks and balances. This can, in some situations, reduce the risk (for example, if more than one is required for approval of certain things)
Some times it's a matter of you really can't/shouldn't trust ANYONE but you have no choice. In these cases, a validating/verifying approach can be helpful.
$ sudo make sandwitch
sandwich: target not found
Agreed, catastrophes are a huge issue. An additional one I know of is some people with no ability to reciprocate respect, who could one day (or already have) administrative access to systems.
These people need checks and balances. If they decide to quit, they would likely do something slightly harmful for "fun" unless someone got to their account first. Most likely the only safe way to let them go would be to literally "terminate" them.
another idea for this, though it involves a bit of work per admin - it's nice to keep a separate login and sudo-to-root password.
Create the normal account (i.e. bio) and the admin account (bio-admin) for a given user. The normal user (bio) can only sudo into that user's admin account (bio-admin), and the admin account has sudo access to root. Set up a couple of shell scripts. Move 'sudo' to 'sudo_base'. Create a sudo script which is something like
#!/bin/sh
sudo_base -u "${USER}-admin" sudo_base $@
then a sudo-passwd scritp:
#!/bin/sh
sudo_base -u "${USER}-admin" sudo_base passwd
And the "non-priv" accounts only have sudo access to 'sudo_base' and 'passwd', and only when switching to their 'admin' subaccounts.
A subset of administrative applications requiring multiple administrators may not be such a bad compromise.
ex:
* change root password (or password to any "wheel" account) - requires multiple administrators to enter the same passwords
*su/sudo'ing to a "wheel" account, or changing said account's privileges, requires the authorization of at least one other wheel'ed user.
* Alterning an active network interface, shutting down, and restarting requires authorization by other administrative users.
Stuff like that, which are things that shouldn't be done often, anyway, and could allow one admin to take over the whole system, seem like good candidates for multiple-approvals. Everything else could be left alone.
The approval process is basically - the root users needs to take the action, and then 2+ non-root (but wheel) users must approve it.
I'm using 'wheel' as that is the group in FreeBSD that is typically allowed access to sudo/su. Not sure how other systems typically work.
Man, that happened to me this morning, cleared out the house. Wonder what I ate?
There's this thing called 'modular programming'. You program things in coherent chunks. For example, you could program a good bit of the lower-level UI level stuff in a chunk (window/panel handling, for example) to handle any system. Now later, you could say "Wait, we could make this faster with Accelerated Hardware X) and then make a second module, that can be accessed in the same way, but uses Accelerated Hardware X. Now, at load time (or install time, or configuration time), it could spend a half dozen cycles to determine if Hardware X is available, and run that module or the default based one the result.
No support is lost, but some platforms will perform better.
If they make the GPU replaceable, it's not such a big deal.
If they underclock the GPU to reduce heat, again, not such a big deal.
A GPU might have an expected 5-10 lifetime at full throttle, but if you knock it back to 25%, you probably will get a much better survival rate.
given your last comment - I think pre-defined hardware such as AMD/Intel desktop chips will always be faster than FPGA for a pre-specified set of individual operations. It's only when you get to operation combinations not defined at manufacture time, but used frequently, that FPGA has an advantage.
The current CPU design will stay for most of the work, and an FPGA attachment would handle the specialty work that isn't needed most of the time, and can be dropped.
This issue is reprogramming time and muti-threaded/multiprocessing apps. If you have five applications requiring different FPGA setup, but only two FPGA cores, time sharing could be quite painful.