for much less of what Assange did.
In Guantanamo and other illegal detention centers around the world, without trial and elementary human rights guarantee, persons abducted by the US and other countries governments are incarcerated for much less that this journalist is doing.
The most foolish thing he could ever do is to go to the authorities of any country; if he do so, he will be in jail for a long time.
>> XFCE also is an X environment (guess why it starts with "X"). Basically, today there's no graphical environment for Linux which isn't based on X.
I was making a point about the bloated contraptions that KDE and Gnome are, also implying that it seems to be an effort to reproduce some "features" from windows or mac that I'm skeptic about...
Nowhere I said that XFCE is not X. I said "be careful choosing an X environment" because since the grown popularity of ubuntu there is less and less visibility of other desktop environments that depart more or less from the typical windows or mac imitators.
Bear in mind that since I was claiming some experience in migrating small to medium companies from proprietary systems to FOSS based ones, I _must_ know how a X desktop systems works
And I'm a fluxbox user myself (after Enlightenment, fwm, WindowMaker, blackbox, and several others that where fugacious in my boxes).
Fer
I did some small and medium business migrations towards FOSS software and I can attest that it's not easy.
Key factors I've encountered are: users have a bad predisposition, they always prefer windows because they (think they) know it, they have it in their home computer, notebook and phone, and they don't want to make the effort to learn another system; there are custom developed apps that not always are easy or at least economically feasible to migrate; there are software that are probably easy to migrate but you lost support if your server is not windows, and you are setting yourself in a position where you will be blamed by any problem a computer could ever have, related or not to FOSS.
In my experience trying to perform a 100% migration is not very easy not desirable: except in very restricted environments, every non trivial system will always be made up of heterogeneous OSes and apps. Because of smartphones, laptops and embedded systems, that mixture is pretty much guaranteed these days. So it's better to move early the back systems: replace mail servers, file servers, databases, printservers, backup systems, http and ftp servers, LDAP, routers, firewalls... and make sure they work and are appropriately configured.
Then deploy OOorg to _windows_ WS, perhaps with Firefox and Thunderbird (I always though that the Thunderbird developers would be looking at Pegasus Mail, sadly they weren't). That way your users will be familiar with the apps and then changing the "desktop" will be more easy. Change the users WS OS progressively, change first the WS of the more "advanced" users and try your best to show the deployment of the "new" system as a privilege; if you can, change the OS and put a new WS for it, or at least a new or bigger monitor.
Important factors in success and collaborative users is to provide them with compatibility: you're migrating, the rest of the world no. So you have to make sure your users can communicate with the external world: not only OOorg has to open xls and doc files; they _need_ to chat in the msn network, watch videos on youtube, and so on. Those are as much as important as to be able to do the work if you want your users supporting you.
Be careful choosing a X environment: the popularity of Ubuntu these days hides the fact that it can be obnoxious and overcomplicated for end users. A smaller, lighter and more orthogonal desktop environment (like XFCE) could be better.
Don't try for the new environment to mimic "look and feel" of windows: it's far more irritating to encounter subtle and minimal differences in behavior that to face a complete different approach. Most users spend 90% of they time in two or three apps (mail, office suite, some custom or enterprise app) and they simply don't care about anything else.
Your ultimate goal is to be asked to install "linux" on their home boxes or laptops. That will happen when they feel comfortable and familiar with the new system.
One thing is hiring for a temporary work, another completely different thing is to hire people to fight against each other for the position.
That's ethically questionable at the very least, and it would be possible only on certain circumstances, like when an economy slow down or crisis push unemployed workers to accept such a deal.
Whoever is the employer has to be able to decide if a person is appropriate for the work or not, and take any risks that a incorrect election would produce.
I would never get into a job in those conditions, I don't want to work in such environment. I like to *collaborate* whit my colleagues and not trying to saw the branch where they're standing to get some rise or privilege.
There are some very skilled persons that are terribly bad at competition, younger people could be intimidated by older one, management sometimes develop preferences, and what not. Competition or basic ecology is simply not always the best strategy.
Apart for that (the ethical thing) this is not the best possible strategy: if you had to do the hiring of three programmers to compete one against the others, you can't certainly put them all in the same project. So this would be make somewhat difficult for you to evaluate the relative performance, and if those three developers are NOT very apart in skills and knowledge, matters are most complicated after they advanced in their respective project, because differences would be subtle and probably arguable. The only strategy that **could** work here would be to assign a non-trivial well defined and designed project to every one an let them work alone, then compare the results. But this would cost 3 times the money and would probably take more than a few months, and you're facing the risk of a *triple* failure.
And, if you're not too idiot, at some point you will be envisioning a merge of the best parts of the three projects.
A good work ethic and honesty
is not hiring two persons to drop them few months later.
He says, 'I imagine they might exist in massive ships, having used up all the resources from their home planet. Such advanced aliens would perhaps become nomads, looking to conquer and colonize whatever planets they can reach.
If they have the resources to build those ships, then they probably don't need us... perhaps they need some material resources, but they can obtain that from quite a lot of planets, not necessarily earth-like, nor necessarily inhabited. Anyway, if they don't rush up, there will be no much resources here also.
You do NOT turn off the car - this could lock your wheel, preventing you from steering altogether. Whats more, you'll lose power brakes - you know - the things that will stop your car quickly. Instead:
Put the car in NEUTRAL. The engine will disengage. Hit the brake HARD. Do not pump. Steer the car off the road, and once its stopped, you can PARK it and turn off the engine.
Brake hard without traction and steering at the same time is dangerous at high speed. This maneuver should not be attempted by a casual or non very skilled driver, the car can easily turn over and end on it's roof. The correct way for control a car in this situation is stop the engine, let the car slow down using transmission-motor brake, and slowly turn to the right, and then get it on neutral and stop. For the FA, I don't know if the engine will speed-down on putting neutral, or it will run wild. If the later, a engine explosion could happen as it goes over RPM, which would cause more confusion to the car driver and the adjacent vehicles.
>>I don't have a TV at home, so the TV spectrum is useless. I don't listen to radio in the car, >>so radio spectrum is useless. So much that we do today would be better suited to a HUGE amount >>of spectrum divvied up and utilized by every device that could hop frequencies as needed to >>find a clean channel, that could raise power needs when a tower is far but drop them >>significantly when towers are near.
WTF?? So you think that if you turn of the radio on the car or the TV set in your house the EM spectrum utilized by broadcasters is free until you turn the radio or TV on? Oh boy.
Barry misunderstands the BASIC transaction basis of currently-free media (like TV): the ADVERTISERS are his customers, the VIEWERS EYES AND ATTENTION is what he's selling and the 'content' is merely bait to attract and hold the viewers for as long as possible.
ADVERTISERS are the customers, VIEWERS (readers) are the PRODUCT. The NEWSPAPER is the MEDIUM.
So in a sense, he's stating categorically that fish are going to need to pay to enjoy the worms hanging on those hooks.
No. In that sense, WORMS are going to need to pay to enjoy hanging on those hooks.
No, if Disney's working on a 'subscription' internet, I'm going to bet strongly that they'll be wrong.
Agree. Who the hell would pay for something that can be obtained almost free?
Things are constantly changing.
Exactly: that's my point. If things are _constantly_ changed, IMHO it's better to get them when they change, not every N [time unit].
My question (above milestones in releases) was a rhetoric one
My point is that the 6-month release cycle is artificial, because is a self imposed restriction to outcast the image of being efficient and scheduled responsible development team, aimed mostly at decision-maker management persons, who knows nothing about technology or software development. This release cycle makes not better system in any way I can think of.
There were are probably _some_ of these releases that carried out some innovation or change in such a way that required or merited to put them as a new "release" or "version" of the system (say you're changing the default FS or some system-wide default or policy) or the kernel has changed in a way that's not anymore backwards-compatible with other parts of the system, or may be a big chunk of the software are about to pass-out as obsolete. These changes happens from time to time and at certain point a new release is a good thing.
What I say, is that these changes are not evenly distributed in time (and IMHO nor that frequent), so there is no point in adhere to a schedule.
Let's put this straight: this release cycle serves only the purpose of getting a feel of innovation (-hey, look, I'm running version 204.54.678, where you're merely running 4.05) and up-to-date status, which I don't say there isn't on OpenBSD, but if this innovation exists, it's certainly not due to the release cycle.
I'm not against OpenBSD in any way, I'm only not convinced of this particular issue is a good one.
Cheers.
I am sysadmin for a number of boxes running some of the three Debian variants (mostly stable and testing in production).
Can someone explain what's the advantage of getting a new release exactly every N months (or days, or years or whatever time unit you like)?
I'm much comfortable with updates and security fixes that gets in my current system whenever the need for them dictates an upgrade for some piece of software (i.e. packages in Debian), in a non-disruptive manner and the most automatically possible, and complete new releases of the distro as a whole when something *really* different is going to get into stable. This barely occurs every six months, and not so frequently every year, in Debian nor in any other system I'm aware of.
This six month release cycle is artificial: what are the "milestones" in those 25 6-months releases?
I think this is only a marketroid artifact.
(Note for Debian haters and illiterates: if you're about to argue that stable release cycle is too long, and need backports for new software, drivers, etc., let me say that for a long time now testing has had security updates too; you're able to get backports or make your own, and even run a mixed stable-testing system if you want, but I don't think the scenario for such a need would be very common having testing with security updates available. If that's the case, you're probably in a situation where every distro or system will need hand tweaking and maintenance too).
"If it ain't broke, don't fix it." - Bert Lantz
