Eh, it depends. I've had plenty of bad luck with Seagate's consumer drives dying pretty quickly. On the other hand, I've yet to have to replace a single enterprise ES (or ES2) series drive. We use Seagate's ES series drives in the arrays we depend on and Western Digital black drives in the arrays we don't care too much about (video editing rigs). Though I said, "Don't care too much about", I at least expected them to last more than a few months. Unfortunately, a few months is a tall order for Western Digital. The black drives die so often that their entire warranty department probably knows me by name...
I agree entirely. What people call a programmer today is merely a job title, not a profession. You are hired as a programmer. That doesn't mean you're good at it, or that you even have training in it. That's just what they call you when you walk in the door, and what they put on your business card.
I work at an institution with about 20 "Programmers". They can barely string together coherent lines of the proprietary BASIC-like language they use for the information system. The web development team uses ColdFusion, and is 3 or 4 major versions behind (MX 7, IIRC?) on their upgrade because every time they think about upgrading, someone gets cold feet. I've even heard a System Engineer (HR for systems administrator) state, in an entirely serious e-mail, that "our institution doesn't support Curl", because we're running an old as hell AIX system, that they have no development server for, and refuse to compile and test packages for it. Not a single one of those brats can write a line of Perl, Python or even any shell either, so we have a vendor on one hand saying "upload data X to Y" and them saying "we can't". They have absolutely no problem solving ability at all, and I'm ashamed to be in the same generally industry as them.
What's worse, is we've worked with a few pretty large vendors recently (our information system vendors, and two CMS vendors), and their code has either been terrible, or has a really really strong, overprotective, IDE smell (where chunks of library code look strangely more uniform than the rest, and take 15 lines to do 1 line of work). One of them actually asked me why one of my randomly generated passwords was "so long". Was he typing it by hand?
I think this is exactly why the thought of driving such a car scares me. It's not the car at fault by any stretch of the imagination, I just don't trust myself driving it. Heck, I was freaked out the first time I drove a car that had electronic throttle control. Not to mention that anti-lock brakes scare the crap out of me (I trust my foot more than the ABS system).
What strikes me about a lot of wannabe "racers" though, is that they often don't even care. Not only do they have no respect for the horrifying power of the 1+ tone object under their ass, they have no respect for anyone else on the road. A lot of garage mechanic kids will tune their suspension aggressively, throw a high rev engine in their car (if it didn't come with one) and drive down back roads as if it were a speedway. Forget the Carrera GT even. Give an inexperienced "racer" a 220~ horsepower Corolla or Integra build and watch them wrap it around a tree or end up in someones yard.
Must be an idle day at the BBC. A couple paragraphs of statistical wank about physical attributes seeming to correlate with password quality. Then a rehash of old news about bad passwords being easy to crack. My hair is unkempt and I have a 62 character password encompassing a good chunk of ASCII printable characters. Bring on the "compensating for something" jokes.
And without having this accessible over the network, network transparency goes to Hell.
Again, we're talking about a protocol for a combined compositor/window manager (they merged them, remember?) talking to clients on the local machine. All they are currently making is A.) the Wayland protocol, B.) A combined windowing system and compositor to demo it with and C.) some demo clients. They aren't trying to make some swiss army protocol that magically solves the problems of local displays and remote displays at the same time. They specifically said that's not what they want to do in the first place. Wayland, in any form, couldn't do that and X11 doesn't do it either. If you think that X11 is some kind of godsend then fine, I personally don't care, but they're trying to make something that performs very well locally right now and X11 is mediocre at doing both of those jobs. Just mediocre, and it won't be doing any better in it's current form. Even X11 forwarding, your most cherished toy, slows down horrendously when having to deal with a lot of difficult to compress image data in addition to dealing with input events. I try to drag a rectangular object around inside another window and... what's that? The rectangle can't keep up with the cursor? It's so slow that I might as well just use Spice, a protocol made for remote desktop (and remote desktop alone) network communication instead? My gosh! Who would have thought!
Now, that being said, now that both compositing and window management duty has been combined and simplified, isn't this where you would want to start writing that remote desktop implementation? One that doesn't tie you to tens of years of legacy that forgoes latency hiding and efficiency (Xlib) or one that's so bare metal that you cry every time you look at how much code you've had to write to do anything (XCB)? One that was written for remote desktop sharing in the first place and not a rehash of the same mediocre mess we've been dealing with untangling for years?
VNC operates in terms of the root window, and thus is completely unusable for this purpose. If Wayland developers designed their own remote protocol (even if it was primarily bitmap-based) and window manager interface, it would at least make their efforts somehow legitimate
So if they don't re-invent not only the wheel, but the drive shaft as well, you won't be satisfied? They aren't trying to do the whole job for you. We (the programmers) are supposed to be doing something besides sitting in the peanut gallery and yelling "do more for us! we don't care about your goals!".
-- maybe even add support for X on top of this for compatibility. But now it's "we will draw pretty pictures, dirty people who need remote applications should use VNC!" -- that's completely unacceptable.
Wait, so you missed the part where they're working to run X within Wayland so that you can still run your X applications if you'd like and still be able to use your X11 forwarding if you so pleased? While they aren't building it into the protocol (again, there's no reason they should), isn't that exactly what you just asked for? I know you aren't supposed to read the article here on Slashdot, but I didn't think you'd go so far as to not read up on the topic at all. That is impressive. You've earned your low number.
I said no such thing.
Exactly. You said nothing at all about what actually triggered the ficticious event you referenced in your fake quote. Not a damn thing. You gave absolutely no context. You just made a vague statement, probably in hopes that nobody would call you on it.
it's not a protocol if you can't use it across the network.
...did you actually say this statement? Wow, never thought I'd hear that. I suppose a sandwich isn't a sandwich if it's not made for eating then? Or doesn't use bread? Please consult a dictionary for that word and get back to me.
And even if it was, there would be still no reason to use it if it is not at least as efficient as X when used for such purpose.
Oh? A protocol and system made for communicating in a low latency environment and relaying large amounts of data around a computer system being slow at communicating over a network? Gosh! Who would have thought. I hear cars don't work well as boats either, even when converted to amphibious vehicles.
There is absolutely no reason for making a WORSE system.
Oh, so you've used this phantom remote desktop system that someone wrote sometime in the future after the desktop portion of it had been completed and actually had some real ground to stand on when evaluating an implementation? Amazing! Can I see it?
You are ignorant. X uses input drivers and its own event system. There wasn't even evdev subsystem for most of the time X existed (and there still isn't on systems other than Linux).
I guess it's a good thing I wasn't talking about X then, huh? The entire paragraph you quoted was about Wayland and Weston. I even mentioned the names of them, would you like me to use blink tags next time? Does Slashdot allow those? If I'm ignorant for actually sticking to a topic without diverging half way through a paragraph, does that make you willfully ignorant since you seem to have intentionally ignored the context?
I think anyone that has watched the creation of new X extensions and deprecation of old ones (usually too slowly) over the years can agree that there's a lot of cruft in X. Nobody is denying that. If you wanted to, you could probably get Keith Packard himself to point you at some cruft that they're trying to remove. They've been trying to clean up for years.
That being said though, I can hardly read your last few sentences as anything but exaggerated nonsense. Wayland, at the very least, has had a system for tracking surface damage for a while now. The notion that the compositor will require a complete surface copy for some arbitrary reason that you didn't specify is rubbish. Additionally, in a remote access context, insinuating that a compete screen copy would be required each time something has changed (for whatever arbitrary reason you also didn't specify) is also rubbish, especially since you already have every client notifying you of surface damage.
Step back for a second, Wayland is a *protocol* and Weston is a work in progress for crying out loud. They haven't even finished hammering out the details of local screens and clients yet, let alone stapling together a recommendation for remote desktop access. The fact that you're trying to draw a conclusion at all at this point is ridiculous. Heck, input is still being pulled in raw from evdev devices isn't it?
The grandparent may have not been so well versed in his Xorg, but that doesn't really warrant the kind of knee-jerk, half-assumed, hostile response you just gave.
I find it incredibly eerie that your institutions entire history almost mirrors mine. Every LMS you used, we used, and I've complained to my boss about almost everything you have. I could almost confidently say that I might actually know or work with you if I didn't know from your website that you're from the state next door to me.
What makes it almost scary was that just today I was speaking to my boss about Instructure being pretty much the last choice to stay away from Blackboard, but with their popularity among the faculty they would probably be bought up next. He then said (fully believing the salesman that came to pitch it to him) that they could not be bought up by Blackboard because their product is open source. I then pointed out that the original author has every right to change the license of their product (though not retroactively) and that a boatload of their major features are actually not open source.
So we, once again, come to a crossroads that really isn't a crossroads at all. We can't run Moodle locally because our IT department is filled to the brim with arrogant and/or incompetent twits. The one Moodle host that we were thinking of going with has been bought out by a company that sells support without actually providing it. Our last hope is Instructure with Canvas, but we can't support it locally because our IT department communicates with each other using grunts and smacking each other with clubs. We could go with their hosting service, but that wouldn't save us from the eventual issue of Instructure being swallowed up by Blackboard.
So hear we are. Doomed to go in a circle over and over until some regulatory body steps in and tells Blackboard no. When we first moved to ANGEL I thought it was a piece of junk (and it is), but now it's a piece of junk owned by Blackboard and that makes my life as an LMS administrator/programmer hell. What makes the buyout of ANGEL scary though, is that Blackboard actually kept the ANGEL interface designer so that they can make the next version of Blackboard look like ANGEL while being functionally (on the back-end) Blackboard. As you work at a college, you already know who the real decision makers are and the real decision makers love bubbly interfaces.
Long story short, we've just been shafted. Again.
It's not hard to admit errors that are [only] cosmetically wrong. -- J.K. Galbraith