Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×

Comment International "ethics" (Score 2) 304

... as they keep saying about Jerusalem, it will go something like this: "Annexed by Russia in a move not recognized internationally."

I recently too a course titled "Ethics in International Relations" at a major college. (This was to fulfill a distribution requirement for an "ethics" class and the particular course had the bonus of also fulfilling an international affairs requirement.)

One of the first points made:
  * Which regions are part of which countries is NOT a subject of international ethics.
A fait accopli is accepted as is. (This was taken as a universal, part of the definition of the boundaries of the field (as taught), which otherwise studied many different, often conflicting, schools of thought.

I interpret this as follows: "International Ethics", as a dicipline, is an attempt by academics (and the rich people who fund them - such as Andrew Carnegie, who largely founded the field) to influence governments, primarily to improve their treatment of the people they rule and otherwise use force upon. ("Improved" being viewed throught the biases of the academics in question.)

In order to sway the behavior of rulers - especially those who are oppressing their long-standing citizens, recent conquests, or those with whom they are considering resolving a dispute with force, they have to appear non-threatening to the rulers' core issue: that the ruler is in charge. So they must strictly avoid challenging WHETHER the rulers rule, sticking to issues of HOW they rule.

So don't expect academia to support any move for self-determination by the people of an occupied region. The rulers that make the claim and have the power to enforce it will be passively accepted.

DO expect them to oppose such people arming themselves to assert a right to self-determination, or even anyone speaking in a way that might "lead to conflict" rather than passification and quiet (but mainly non-violent) suffering. Thus you see them supporting things like censorship of speech an arms blockades to regions of conflict - which are then selectively enforced and lead to "ethnic clensing" genocides by the side that more successfully evades them against the side that is now largely disarmed.

(Example on censorship: During the period where the Benghazi attack was being blamed on a video posted on YouTube, Sarah Chayes, a senior associate of the Carnegie Endowment for International Peace, wrote an op-ed for the L.A. times calling for its censorship.)

Comment Re:WOWZA! (Score 1) 240

I stopped using any apps with adverts in them 3-4 years ago due to power drain

Simple fix. Root your device and install a hosts file made to block ads. Several apps out there do this for you.

Or, you could always keep a charger handy, even one that runs on AA batteries, or built-in Li-Ion.

Comment Re:Caution (Score 1) 117

There's rather little point in suspending a server:

Those of us who do this stuff happen to disagree with you.

even ones that are off outside business hours are better off hibernating rather than suspending.

"Better off" HOW? Hibernation takes much, much longer on both ends, and the difference in power consumption between hibernate and suspend is nominal. When your cluster suddenly needs more power, you don't want to wait 10 minutes for POST, kernel booting, and copying quite a few GBytes from disk into RAM, when you can instead get up and running in a few seconds.

Comment Re:Coupled with systemd and LinuxBios (Score 3, Informative) 117

The third big software factor is the BIOS. "coreboot", formerly "LinuxBIOS", is blazingly fast compared to most proprietary BIOS's. It has made some inroads but is still not available for any commercial systems I can find. So no matter what is done in the other two factors, the BIOS is still a limiting factor of suspend and restore delays.

POST has to be performed by the BIOS when restoring from hibernation, but NOT suspend. So no, the BIOS is NOT a significant "limiting factor of suspend and [resume]" operations.

Comment Not fragile: Redundant. (Score 1) 33

This actually looks good to me. Most helicopters can be shot down with a rifle. They are huge engines with large fuel tanks and large, whirling blades, and it is not that difficult to get them to destroy themselves with their own momentum, height, or fuel.

I concur. Helicopters are a collection of single-points-of-failure, disasters waiting to happen. (Particularly the pilot - they have to be continuously controlled and crash almost instantly if anything incapacitates him.) Their vulnerability is justified only because their extreme usefulness oughtweighs it. With eight rotors I'd be surprised if this vehicle couldn't at least come to ground safely with at least two of them destroyed, and the multicopter approach has been under autonomous computer control from the start - made practical only by the automation.

I envision this thing's missions as being primarily extreme rough-country ground transport, with short hops to bypass otherwise impassible terrain, reach otherwise inaccessible destinations or targets, attack from above, or put on a burst of speed when time is of the essence. Think a truck-sized "super jeep" ala Superman. Being primarily a ground vehicle lets it perform longer missions and reduces its visibility and vulnerability compared to a helicopter.

Just because you CAN fly doesn't mean you DO fly all the time. As is pointed out in the webcomic Schlock Mercenary: "Do you know what they call flying soldiers on the battlefield?" ... "Skeet!"

Comment Re:Rebooting is not a fix (Score 1) 136

On the flip side, spending six weeks fixing an issue on a single server running a non-critical, non-time-sensitive service which occurs once or twice a year and is 100% worked around by a reboot probably isn't an efficient use of your time.

In the long-term, it is. If you let issues like that continue to exist, then you'll get stuck with an unnecessary proliferation of servers, with each running just one service, so rebooting one doesn't take the others down.

Not to mention that you'll find that you get stuck maintaining multiple, overlapping services, because the first one wasn't reliable enough for the tasks some department decided to bring-in, later.

And also, I don't think I've ever seen a service that was non-critical and non-time-sensitive. Whatever it is, people won't even try to use it until the very last minute, when they need it to work immediately. It could be a damn web page that just hosts the phone extension list, and because HR needs to call someone about something simple, at 5pm on Friday, that server is now delaying everyone's paychecks. EVERYTHING ends up being varying degrees of critical.

Comment Re:Rebooting is not a fix (Score 3, Insightful) 136

"Reboot does not fix anything, it just hides things".

That's not specific to rebooting... It's more a question of doing root-cause analysis, versus quick bandaids. I'm firmly in the RCA camp, but sometimes it's the companies that are to blame, rather than the individual admins. Some companies are heavily slanted towards always getting the quickest possible workaround, rather than ever actually finding and fixing the problem. It's one of those false-economies, like counting lines of code and similar.

Comment Re:Tmux (Score 3, Informative) 136

For my use cases, I could not find a compelling reason to use tmux

Obviously if you've been limiting yourself to the features of "screen" for many years, you're not going to think you need the added features of "tmux"...

A big one is sharing:
"window can be linked to an arbitrary number of sessions". If you or somebody else has a screen session open, you don't have to detach it from their terminal to see what's on it. You can just attach it to your terminal as well. Works great when you've got a session attached to your desktop, then want to access it on your laptop/tablet/phone/etc. The tmux session will even change geometry to match the smallest terminal window.

Being more lightweight and responsive is good. Saner keys for some functions, like ctrl-a pg-up to access scrollback. And just the fact that it's still getting active development is an important feature.

Comment Re:no one would HIRE them, either (Score 1) 581

Older coders are sitting around doing nothing, and there's gold in them thar hills.

It'll cost you an order of magnitude more to provide them health insurance... Maybe double or triple that again, if the plan includes aging wifes as well.

And while they might be very good, I wouldn't expect them to be as willing to do on-call rotation, put in extra hours when deadlines loom, not use their vacation days, etc.

It's not a bad idea at all, but there's sure going to be some major downsides to a company with predominately older people.

Comment Re:no one would HIRE them, either (Score 1) 581

(I'm over 50, have been looking for work for a while now, and I'm getting nothing; no interviews and certainly no offers. I have a lot of experience and a good work ethic, but it does no one any good if the companies routinely dismiss anyone with more than 2 pages of resume experience,

You're doing something wrong... Nothing on your resume has to show your age, and you certainly don't have to have more than 2 pages, just because you have lots of experience. Resume writing 101. Limit yourself to the latests 3 jobs, or so. Nobody wants to look through a 10-page resume, so if you don't have good-stuff on the top page, recruiters won't bother.

since they are seen as 'too expensive' to hire).

Lots of recruiters ask for your salary requirements up-front. I generally refuse to answer, but if you low-ball it, you'll do just fine. Hell, my last company, though predominantly young, with lots of H1Bs, had several grey-haired programmers, and I recently hired an older gentleman myself, who was only looking for work after his company (where he put in 25 years) went out of business.

Slashdot Top Deals

"I say we take off; nuke the site from orbit. It's the only way to be sure." - Corporal Hicks, in "Aliens"

Working...