The server is up 99.99% of the time. The server's T1 is up 99.99% of the time. T1's ISP is up 99.99% of the time. The backbone provider is up 99.99% of the time. The cellular ISP is up 99.99% of the time. The cell-to-tower linkage is up 99.99% of the time...
I'd assumed people wanted five 9's, but let's say it's four.
Multiply those together, and you've still got over 99.94% reliability. I'd argue that the reason we're even having this discussion is that there's far less reliability than that.
With four nines, at 100 points of failure, you still have 99%. With five nines, you can go to a thousand points of failure and still have 99%. And that's assuming all of these points of failure are individual "single points of failure", in that they are all interdependent -- which often isn't the case.
Of course, 99% sucks -- that's still almost four days of outage per year. 99.9% means you're down to a few hours per year, which still isn't good, but for a hundred points of failure, it isn't bad, and it certainly isn't what we see. (And I'm not really talking about cell phones -- you can't predict the weather.)
Why reload the whole damn OS when restarting a process will do the same thing?
Because for people who don't know that, it's easier to say reboot.
Easier to say that than to:
Transparently restart a service they probably aren't using (like the printer)
Tell them to restart Firefox
Tell them to log out and back in again (faster than a reboot)
There are still going to be occasional reboots (kernel updates), but just about everything else can be handled more gracefully, regardless of user knowledge. And a mentality where absolutely every update requires a reboot, and, in fact, your next set of updates will refuse to install until you reboot, is going to cause problems for the more knowledgeable people.
Not done much work with NFS then, I take it ? Or services that have long timeout periods and don't die nicely ?
Depends on your NFS hookup. If both endpoints are on the same network, and the endpoints (and network) are reasonably reliable, you're not going to have that problem. In the case where you do, it'll lock up until the server comes back online. The assumption is that NFS might be as critical to the machine mounting it as any other filesystem -- what would you do if a local NTFS partition (like, say, C:) died?
That said, on a home network, it makes more sense to mount it soft, and let it timeout -- and this is an option now.
I struggle to believe anyone has been using Linux for "13+ years" and can only "count on one hand the number of times a reboot solved any problem".
Given your NFS scenario, I can believe that it would be less than five times. That is, the NFS server disk died... Actually, that's about it, some hardware in the NFS server died. If it was a network switch, it's actually better that it waits for ever for you to pop in a new switch.
If you can't afford "multiple machine redundancy" then you don't need 24/7 uptime.
Agreed.
At the same time, it's nice if there are far fewer reboots than hardware failures (or upgrades), as even if you don't need (or can't afford) 24/7 uptime, I think we can all agree that more uptime is better than less, all other things the same.
Even with multiple machines -- let's say you've got two -- more uptime is better. While you're doing that reboot, if your other machine has a hardware failure, you're dead.
It's a fair question, but I think it falls more into the category of "Why the hell would you ever need that?"
In other words, palindromes are already a contrived example, but one could certainly imagine an "online palindrome checker" or "palindrome finder" or something similar. In that context, you absolutely do want to throw away sentence structure and punctuation.
There is one more consideration: This being Ruby, any decent implementation is going to be less than ten lines of very readable code. Thus, if you ever needed to check that it was doing what it's supposed to, you could go read the source. And this being a simple, contrived example, you could almost certainly extend it, in a backwards-compatible way, to allow case-sensitivity, punctuation, and whitespace, either as individual options or as one giant "raw" option.
That said, this being a simple, contrived example, it's going to be pretty subjective, anyway.
It's hard to take a programming language seriously when the official way to copy a file in said language involves two File objects, a BufferedReader and a BufferedWriter. I think it's reasonably safe to assume that most OSes have a standard API for copying files that Java could call - and if that isn't an option Sun could transparently implement everything in Java.
I know for a fact that neither POSIX nor Linux provides a "copy" API. Sure, cp might be more efficient than Java, but it's still actually reading from one file and writing to another.
Which means that copy-on-write is impossible to do at the filesystem level.
Still, it would be much better if Java provided an API for this.
Java is nice, but only if you work in a pure Java environment and can set up everything so yu don't need to talk to the OS much.
That is true. That's also the point of Java.
At the very least, I would guess the average Java app is more accidentally portable than the average C# app, where calling out to OS libraries is dirt-simple, and done often enough that most of them have a better chance of running under Wine than Mono.
But no, I wouldn't recommend Java, I just wanted to point out that if you're going to do it, Eclipse is pretty damned good, and there are things I miss, even in Ruby.
When his XBOX finally died, he contacted Microsoft to make sure that he could send the console in without having the exterior case replaced or damaged. Microsoft ensured him that his request would not be a problem.
Maybe he wasn't clear enough? Maybe he should've pointed out why he wanted that case?
Seeing as Foxit is a stand alone EXE, how is it crashing firefox?
To be honest, I don't remember. It might have provided a plugin (and a plugin is perfectly capable of crashing Firefox). Or it might only exist as a standalone program, and I might have been sick of downloading files and opening them in Foxit, instead of just looking at them in a plugin. I'm not sure which.
I don't boot Windows often enough to care, though.
If you asked "How would you weigh a Boeing 747", the obvious answer is not "Call Boeing". When you call Boeing to request the weight of a 747, you are not doing any actual weighing and it can definitely be argued that the question asks you to undertake the actual weighing process.
In which case, let me clarify the answer: "I wouldn't. I would call Boeing instead."
What you should have asked instead is, "How would you determine the weight of a Boeing 747?" Phrasing it like that makes it a lot more clear that you are only interested in how the person would go about finding out the weight of a 747 and not the actual physical process of weighing an object.
Yes, that does make it more clear. That may or may not be a good idea, though. This is about finding out if you've got a clever, practical person, and such a person would (hopefully) first attempt an easier solution, even if they had to go ask for a clarification. Think about it: If your boss told you to weigh a 747, wouldn't the first thing out of your mouth be "Can't we call Boeing and find out? Or do you want me to do it myself?"
I did not mention Python, but I feel like I should now. The main advantage I see there is speed, and the fact that python can be bytecode-compiled, in case writing closed-source apps is a requirement.
Also, both Python and Ruby have some sort of Java runtime port, though I have no idea what the status of them is.
I also feel like I should mention why I don't like Java: Compared to other languages, Java tends to be verbose, limited, and not really have any advantages other than a decent bytecode runtime. It was a reaction to the complexity of C++, but it solves that by removing features.
I'll point you to this discussion, in which points are made both ways about type safety. I like this quote in particular:
A team has to have ingrained discipline around unit tests and continuous integration. Once you have that, compiler is just an extremely weak and limited form of unit testing.
I tend to agree -- I think automated tests (unit and otherwise) are essential, and once you have that, your tests will tend to protect you from type errors.
That said, it's a big enough debate that there probably isn't one right answer, or at least, you will become a better programmer by learning about both sides. (The same goes for any major differences between languages. A quick list of languages to learn just to challenge how you think: JavaScript (as taught by Douglas Crockford), LISP, Haskell, Erlang, C (really), and a traditional OO language like C++, C#, or Java.)
most compilers will deal with that sort of code in a way t make it more efficient in the run time.
Ruby is interpreted.
The irony here is that, even if I came up with the perfect solution which only scanned the string once -- as another poster pointed out, this means no 'downcase!', but rather, a case-insensitive match inside the loop -- I'm already taking way longer than the simple solution.
Basically, the shorter you can keep your code (in just about any language), the better. In C, you'd want to take advantage of library stuff on the offchance that some of it is done more efficiently, or will be in the future. In Ruby, you know the library stuff is more efficient, as most of it is written in C.
However, the real absurdity is that someone would actually ahve tow rite that in this day in age. Really, it should be done and put in an engineering book.
Or an interview question. Which is exactly what that was: An interview question.
It is really frustrating to me that the software industry refuses to grow up.
In other industries, you generally do what you're paid to do. You give opinions, sure, but if the customer really wants to screw themselves over, that's for them to decide.
A real programmer would see that uselessness of the exercise, and demand a lot of reasonably sounding specification which would inevitable end up lost in some managers inbox some where.
That's ironic -- a real programmer would demand more bureaucracy?
You're talking about desktop apps, I think. If that's the case, I can suggest KDevelop and Qt, but I have no idea how good they are, and there's always the licensing fee if you produce anything commercial.
Of what I have worked with:
Eclipse rocks for Java development. It's probably decent for other things, too -- I haven't used it for much more than editing JavaScript (VERY different than Java) since college.
Kate is decent. It has some very cool features, and some really horrible and twisted ones. It's at least lightweight enough for me to move (mostly) away from Vim, though.
Perl has CPAN. It has a library that already does what you're trying to do. I say this without knowing what you're trying to do, because that's how freaking huge CPAN is. If you can think it, there's already a CPAN module that does it, to some extent.
Believe the hype: Rails is damned good. And, because of Rails, there are a lot more rubygems out there. (Rubygems is like CPAN for Ruby, only there's not as much stuff.) And you can always find an HTML form designer, if you really need one.
Firefox has Firebug, which makes Javascript a serious possibility. And Javascript is almost as powerful as Ruby, and has tons of classes. I mentioned Rails first because you'll still need a backend...
Or maybe not? Adobe is porting AIR to Linux, and AIR includes Webkit. So you can develop a cross-platform, client-side Web application, have it talk to a SQLite database. I'm not sure what's available in the way of tools, though, especially on Linux.
Java is now open source. Since C# was basically built to counter Java, you could always try that (see Eclipse). I hate it, though.
By the way, what do you mean "crashing Adept"? If you mean "you got an error", I don't know, but if you mean "Adept actually crashed, and I got a bomb symbol and everything", you can always open up a Konsole and type "sudo apt-get install lazarus".
But to be able to really recommend something specific, I'd have to know what you're developing.
There is "transparent" with regards to something "agnostic", which is like your "Transparent to the User". I can't define it particularly well, except by example: The POSIX filesystem API is storage-agnostic, which means that we can make accessing network shares transparent with regards to the filesystem API -- or we can implement a filesystem in RAM, and most of our programs would never know the difference (at least until we ran out of swap). The Linux block device API is device-agnostic, which means we can do transparent encryption -- that is, transparent to the filesystem, which just sees a block device.
This makes sense in that you can see through all the cogs whizzing around to see what you wanted to. It's not that the cogs are hidden, it's that you only see them if you look for them -- otherwise, you just see through to what you were really after. (My filesystem didn't want cyphertext, it wanted plaintext.)
There is also "transparent" as a contrast to an opaque (black) box. Instead, the mechanism is inside a transparent box, and you can see the cogs if you really want to. This is about open-ness -- open source, open standards, etc. The same is true for "money people".
I don't see a contradiction, though, as I look at both of these things as opposed to an opaque wall, preventing me from seeing what I want to. Transparency enables me to see what I want to see.
So, in that sense, perhaps there is a better metaphor, because transparency is a bit confusing when we try to compare it to a real-world object -- a "transparent" steering system means that you turn the steering wheel, and your wheels turn, without you having to know what happens under the hood. But a "transparent" hood means you do see everything under it. A well-designed car should allow for both -- I shouldn't have to look under the hood, but if I do, there should be labels and possibly diagrams, and I should be able to change my own oil, etc.
I don't think Linux is the answer to absolutely everything. I do think that it's very relevant, and in many cases, even its price is worth considering.
A few off the top of my head -- the EEE PC and Amazon EC2. If Amazon had to pay a license for every copy of an OS they run, EC2 would be a lot more expensive -- and Asus didn't want to have half the price of the laptop be for the software.
Now, Windows has gotten better at most of the things on his list... but it is something to consider. What is Windows buying you? And what is it actually costing you?
It's often been said that, on the desktop, Linux has to beat Windows by a lot for it to be worth the switch, due to lack of application support and a (mostly gone) learning curve. The same is true of Windows on the server -- even if Windows is better than Linux, or any other Unix, is it better enough to justify the licensing fee?
(That's a long way of saying: I challenge Microsoft's TCO studies, and I think Linux does better. But it's not an absolute, by any means.)
If you are not going to even read my post, don't bother replying.
I will say this:
Didn't you also state that AMAROK (some app you use on Linux) took up 100% of a CPU? Bug or not, that still happened to you...
This one, it's possible I didn't make clear. It takes up 100% of one CPU, in an obscure bug involving me unplugging the soundcard, and plugging it back in. By closing it and re-opening it, the problem is eliminated -- no need to kill it, even. So we can stop talking about amarok -- unless your whole argument is going to be that we need three cores so that we can still work when two threads are stuck in infinite loops.
I'd say, if you have two threads stuck in an infinite loop, you have a bigger problem.
The rest of your post has descended into name-calling, arguments from authority, and a re-iteration of points I've addressed... all in the post you just replied to.
By the way, in case you were wondering, your "years of experience" get you exactly as much respect as it did this guy.
More support calls from people who want to play Wow on crappy computers, and will then complain about framerates.
So what?
People can go out and spend 1500 dollars on a computer and it doesn't do even basic things like play games (Intel integraged graphics!)
What is "integraged"?
Seriously, though, most games will scale down decently to a modern Intel graphics card.
Also, you seem to think that playing games is a "basic thing" -- you're obviously not the target market. That said, my brother did get Warcraft 3 running on his.
What good is an 8GiB iPod when your computer only has 4 GiB of disk space?
Wow... Are you really that stupid?
An iPod is a hard drive with a music player attached. So you could, I don't know, store files on it? Or play music from it?
What good is 60 gigs of space when most of Joe Consumer's biggest files are already on his iPod, anyway?
What do we do for all those people that openoffice simply doesn't cut it
They either don't buy an EEE, or they put XP on it.
However, that barrier is dropping rapidly. Consider someone who travels around with PowerPoint presentations -- they're mostly going to work in OO, and this thing is smaller, more portable, and boots faster.
If anything we should be making sensible moves in the other direction: Computers that (may) cost more but aren't crap, which then can synchronize with these little sub-notebooks
I know! Since they don't have to be portable, we can make them pretty big... just put them on top of someone's desk. I think I'll call it a "desk-top"!
actually using these as a primary machine
Who mentioned using it as a primary machine, except you?
I'd suggest that clever answers to these riddles can help, especially if the interviewer isn't attached to a "right" answer.
For example: "How would you weigh a Boeing 747?" Obvious answer? "Call Boeing."
I would say, any candidate who doesn't at least try that should be gone. Somewhere on The Daily WTF is an article which explains it best -- I'll try to quote from memory: "Which would you rather have working for you? The guy who takes the plane down to the docks and puts it into some water-displacement apparatus? Or the guy who calls Boeing?"
I know that no matter which side of the table I'm on, any answer other than "Call Boeing" is severe NIH syndrome, and should tell me something about what the actual work will be like.
I beg to differ -- Webkit is actually pretty damned good, in terms of speed, stability, and compliance. About the only thing it lacks is universal support from webpages, but then, that used to be a problem for Firefox -- there's not a whole lot a browser can (or should!) do about sites that don't follow the standards.
Why do we even still use html?
I'm going to say IE. Whatever replaces HTML must work in IE, and it must do so without any fuss.
But that's only because I'm assuming we'd replace HTML with something like XHTML, which is (inexplicably) broken in IE.
why not use something like PDF or flash for a fully graphical web?
PDF is no more or less "fully graphical" than HTML. In fact, if I remember right, PDF is based on PostScript, which is a Turing-complete language designed to format documents for printing -- sounds pretty textual to me.
Flash might be, but do you really want the Internet to be based around keyframe animations?
The difference is, HTML is designed for the Web.
PDF is designed for print. I'd much rather have a website which I can resize to any window I want, and let the text flow to fit, than a PDF document which has pages that are certain proportions, exactly, leaving huge margins and gaps between pages for no reason. PDFs certainly have their place, but the Web ain't it.
And I only say that because I don't know enough about the other capabilities of PDF to know if it can quite replace the Web as we have it -- plugins, javascript, video, etc.
Now consider Flash. Adobe certainly seems to want this to happen. AIR embeds a SQLite engine, a Webkit engine, and probably some other things as well, basically allowing you to develop a desktop app in HTML and Flash -- but since it's Webkit everywhere, you don't have to worry about browser compatibility. And Flash itself keeps getting more and more capabilities, though it still sucks for video, and still isn't hardware-accelerated at all in the browser window.
But it's really frightening that you want to replace HTML, an open standard that works just about everywhere, with Flash, a wholly proprietary system that is only relevant to this discussion because Adobe has seen fit to port it to enough platforms. I'm still waiting for my 64-bit Linux Flash, and I can't do a damned thing about it, other than contribute to reverse-engineering projects like Gnash.
And yes, I know you can get the SWF spec. You can get it under a license which forbids you from developing a player. Woo hoo.
While it would make writing crawlers and accessibility harder, I think that is something that could be worked on,
Stop right there.
You want us to stop working on improving HTML engines, and start working on adding features that don't currently exist to PDF or Flash? And then write a browser around them?
Think about that for a minute. Do you really expect it to be easier that way?
that can be parsed easier than html.
HTML is easy to parse. It's even easy to render. It's broken HTML that's hard.
And XHTML would be even easier -- but again, there's that Internet Explorer problem. That, and most websites aren't ready, either.
Now, if your suggestion was to start over completely, I'd be all for it. There are many things I wish had been done differently. But that would take an order of magnitude more time and effort than your crazy-assed PDF and SWF ideas.
Foxit is nice on Windows... or would be, if I could get it to install, and not crash Firefox, etc.
On OS X, there's Preview, and on Linux, I mostly use KPDF. Both are small and fast. Both have browser plugins -- at least I assume Preview does, it's been awhile.
I'm not really sure how "indirectly" spawning threads and "manipulating" them is really any different than simply giving extensions a threading API.
The real problem here is that we are trying to create a safe sandbox such that extensions can be reasonably portable and somewhat safe, and actual websites can behave like applications and be absolutely safe. Anytime we give the extensions more power, there's the potential to break extensions, or make the browser unstable, make it harder to write safe extensions, etc. Anytime we give web pages more power, there's all that and more.
And threads are very powerful and very tricky under the best of circumstances.
But again, nothing really special about threads. Just about anything else falls under the same umbrella. Anyone remember popup ads?
why not? if it sees you have a couple of gigs FREE, what harm is there in using it?
Because then I want to use them for something else. Like my OS caching files, or some other program. In the first case, Firefox is assuming it's more important than whatever files I'm looking at locally. In the second, Firefox is going to get swapped out, which slows things down quite a lot.
The sane way to do this might be to have Firefox limit itself to something sane -- and consistent, irrespective of RAM size -- and push the rest out to disk. If there's really so much RAM lying around, it won't kill Firefox to let the OS cache things as files. Not as ideal as, say, a global OS-managed HTTP cache, or even something like memcached, but it would mean the OS gets to choose what the RAM gets used for, which is a lot better than Firefox deciding for itself.
That said, last I heard, the RAM usage was from fragmentation, which is technically not a memory leak, but is a way to leak memory.
p.s im on a gig system now and firefox is using 100MB so the chances of it eating 2GB are slim
Oh, bullshit. You are ONE person. I've seen probably hundreds of comments about Firefox eating up tons of RAM after only a few hours or days of use. It may well work for you, but that just means you haven't hit the problem yet.
who can forge hard-working programmers into good and hard-working programmers.
Not going to happen unless they were already decent. Not good, decent.
Let's take an example from my interview... How would you check that a string is a palindrome?
A clever programmer might do something like:
sentence.reverse == sentence
A programmer somewhat more concerned with efficiency might iterate over the string, character by character, comparing the first half with the second half.
A more thorough, correct programmer would do either of the above, but stick a
sentence.downcase!
in front of it -- probably also strip out punctuation and spaces.
And then there are the WTF programmers, who will do something like:
i = 0 result = true while i < sentence.length case sentence[i] when 'A' if sentence[sentence.length-i] == 'A' # yup else result = false end when 'a' ...
Oh, and the above won't actually work as written, aside from being absurdly inefficient both in coding time and in runtime if it did work. The amount of effort it would take to mold someone who would actually write the above into a decent programmer is not worth it.
Compare that to someone who wrote the first example (sentence.reverse == sentence) -- remind them about whitespace, punctuation, and capitalization, and they'll be able to work it out.
Now, absolutely, if you can't do this stuff yourself, hire someone who can. That part is tricky, but the complaint of the original article was not that they didn't know how to find any good programmers (or even superstars), but that they couldn't find enough.
And absolutely, one "star programmer" is not as important as a team that works well together -- but a "star project manager" isn't a silver bullet either.
Retooling the whole thing won't make a different in that regard. We may up the bar a little, but that won't last for long....
On the other hand, I wouldn't mind an overhaul on DNS and SMTP to slow some spammers and other jerks down.
Same applies to your suggestion. Should I break out the "your idea will not work" form? (I'd check the "Nice try, but I don't think it would work", I suppose)
Not just "talking", like yourself... but, in MYSELF? Actually DOING:
Great, thanks for proving my point.
Now, why the irrelevant insult about wasting time on Slashdot? Is it possible that you have no valid points left? Maybe you never did?
I had to point out that: Forking processes is heavier on nearly every level vs. threads
Why?
No, seriously, let's pretend that I didn't know that. Let's pretend that when I said "no significant difference", what I really meant was "No difference at all! Everyone should use OS processes!"
In fact, let's ignore the fact that these "full OS processes" on some platforms are faster than "OS threads" on other platforms. Let's not even bring up which platform is which.
What relevance does this possibly have to the current discussion?
Put it back in context. I know you can do it, I just don't know why it always takes five posts to force you to make the connection...
It matters very little whether we talk about the 130 or so processes that are running on my laptop now, or the 150 or so threads. Either way, they are using less than 10% of one core -- or, more likely, less than 5% of each. You suggested that background threads could actually add up to fill one core:
You don't get it, do you? If you have enough of them running, they can 'eat up' a single core CPU setup's cycles, just like anything could eventually in enough numbers... that is the point I was making:
Have you retracted this position?
Because this means, at the current rate -- that is, assuming the kinds of background processes I currently run -- I would need 10 times as many running as I have now before they filled up a core. And that's on my laptop, which is slower.
In that context, the choice of threads vs processes is completely irrelevant. The programs are already written. And even assuming processes are ten times slower (which they aren't), that only further proves my point -- I'm running a pile of (according to you) inefficient background processes that still don't eat up a tenth of one core. Were they more efficient, it would just mean it would take me doing that much more than ten times as much as I do now before triple core buys me anything more than faster povray renders.
Do any of the articles you linked to make the above untrue? Do any of them prove that a typical desktop user gives a flying fuck how efficient the multitasking is, as long as it feels fast?
Or have you managed to prove yourself as even more of a clueless geek than I am?
If so, you better make damned sure the law specifies that it is about corporate IP.
I'd really rather be able to continue to make one-off Slashdot posts and know they are copyrighted, at least for a reasonable amount of time. I wouldn't mind putting them under a Creative Commons license, even the more BSD-ish one (attribution), but those all require copyright to be effective.
That's a requirement, but it's also a loophole. Disney hardly depends on Mickey Mouse to run, so if it gets too expensive, they can simply transfer it to an individual.
So no, I don't think this can really be made to work, without a reasonably long leading "free" copyright. Might also be nice to have a longer "attribution-only" copyright.
Slashdot Mirror
I'd assumed people wanted five 9's, but let's say it's four.
Multiply those together, and you've still got over 99.94% reliability. I'd argue that the reason we're even having this discussion is that there's far less reliability than that.
With four nines, at 100 points of failure, you still have 99%. With five nines, you can go to a thousand points of failure and still have 99%. And that's assuming all of these points of failure are individual "single points of failure", in that they are all interdependent -- which often isn't the case.
Of course, 99% sucks -- that's still almost four days of outage per year. 99.9% means you're down to a few hours per year, which still isn't good, but for a hundred points of failure, it isn't bad, and it certainly isn't what we see. (And I'm not really talking about cell phones -- you can't predict the weather.)
Easier to say that than to:
There are still going to be occasional reboots (kernel updates), but just about everything else can be handled more gracefully, regardless of user knowledge. And a mentality where absolutely every update requires a reboot, and, in fact, your next set of updates will refuse to install until you reboot, is going to cause problems for the more knowledgeable people.
Depends on your NFS hookup. If both endpoints are on the same network, and the endpoints (and network) are reasonably reliable, you're not going to have that problem. In the case where you do, it'll lock up until the server comes back online. The assumption is that NFS might be as critical to the machine mounting it as any other filesystem -- what would you do if a local NTFS partition (like, say, C:) died?
That said, on a home network, it makes more sense to mount it soft, and let it timeout -- and this is an option now.
Given your NFS scenario, I can believe that it would be less than five times. That is, the NFS server disk died... Actually, that's about it, some hardware in the NFS server died. If it was a network switch, it's actually better that it waits for ever for you to pop in a new switch.
Agreed.
At the same time, it's nice if there are far fewer reboots than hardware failures (or upgrades), as even if you don't need (or can't afford) 24/7 uptime, I think we can all agree that more uptime is better than less, all other things the same.
Even with multiple machines -- let's say you've got two -- more uptime is better. While you're doing that reboot, if your other machine has a hardware failure, you're dead.
It's a fair question, but I think it falls more into the category of "Why the hell would you ever need that?"
In other words, palindromes are already a contrived example, but one could certainly imagine an "online palindrome checker" or "palindrome finder" or something similar. In that context, you absolutely do want to throw away sentence structure and punctuation.
There is one more consideration: This being Ruby, any decent implementation is going to be less than ten lines of very readable code. Thus, if you ever needed to check that it was doing what it's supposed to, you could go read the source. And this being a simple, contrived example, you could almost certainly extend it, in a backwards-compatible way, to allow case-sensitivity, punctuation, and whitespace, either as individual options or as one giant "raw" option.
That said, this being a simple, contrived example, it's going to be pretty subjective, anyway.
I know for a fact that neither POSIX nor Linux provides a "copy" API. Sure, cp might be more efficient than Java, but it's still actually reading from one file and writing to another.
Which means that copy-on-write is impossible to do at the filesystem level.
Still, it would be much better if Java provided an API for this.
That is true. That's also the point of Java.
At the very least, I would guess the average Java app is more accidentally portable than the average C# app, where calling out to OS libraries is dirt-simple, and done often enough that most of them have a better chance of running under Wine than Mono.
But no, I wouldn't recommend Java, I just wanted to point out that if you're going to do it, Eclipse is pretty damned good, and there are things I miss, even in Ruby.
Does the fact that this is expected make it any less disgusting?
No, seriously, are we that fucking complacent that we just accept bullshit just because it's a corporation???
From TFA:
Maybe he wasn't clear enough? Maybe he should've pointed out why he wanted that case?
To be honest, I don't remember. It might have provided a plugin (and a plugin is perfectly capable of crashing Firefox). Or it might only exist as a standalone program, and I might have been sick of downloading files and opening them in Foxit, instead of just looking at them in a plugin. I'm not sure which.
I don't boot Windows often enough to care, though.
In which case, let me clarify the answer: "I wouldn't. I would call Boeing instead."
Yes, that does make it more clear. That may or may not be a good idea, though. This is about finding out if you've got a clever, practical person, and such a person would (hopefully) first attempt an easier solution, even if they had to go ask for a clarification. Think about it: If your boss told you to weigh a 747, wouldn't the first thing out of your mouth be "Can't we call Boeing and find out? Or do you want me to do it myself?"
I did not mention Python, but I feel like I should now. The main advantage I see there is speed, and the fact that python can be bytecode-compiled, in case writing closed-source apps is a requirement.
Also, both Python and Ruby have some sort of Java runtime port, though I have no idea what the status of them is.
I also feel like I should mention why I don't like Java: Compared to other languages, Java tends to be verbose, limited, and not really have any advantages other than a decent bytecode runtime. It was a reaction to the complexity of C++, but it solves that by removing features.
I'll point you to this discussion, in which points are made both ways about type safety. I like this quote in particular:
I tend to agree -- I think automated tests (unit and otherwise) are essential, and once you have that, your tests will tend to protect you from type errors.
That said, it's a big enough debate that there probably isn't one right answer, or at least, you will become a better programmer by learning about both sides. (The same goes for any major differences between languages. A quick list of languages to learn just to challenge how you think: JavaScript (as taught by Douglas Crockford), LISP, Haskell, Erlang, C (really), and a traditional OO language like C++, C#, or Java.)
Ruby is interpreted.
The irony here is that, even if I came up with the perfect solution which only scanned the string once -- as another poster pointed out, this means no 'downcase!', but rather, a case-insensitive match inside the loop -- I'm already taking way longer than the simple solution.
Basically, the shorter you can keep your code (in just about any language), the better. In C, you'd want to take advantage of library stuff on the offchance that some of it is done more efficiently, or will be in the future. In Ruby, you know the library stuff is more efficient, as most of it is written in C.
Or an interview question. Which is exactly what that was: An interview question.
In other industries, you generally do what you're paid to do. You give opinions, sure, but if the customer really wants to screw themselves over, that's for them to decide.
That's ironic -- a real programmer would demand more bureaucracy?
You're talking about desktop apps, I think. If that's the case, I can suggest KDevelop and Qt, but I have no idea how good they are, and there's always the licensing fee if you produce anything commercial.
Of what I have worked with:
By the way, what do you mean "crashing Adept"? If you mean "you got an error", I don't know, but if you mean "Adept actually crashed, and I got a bomb symbol and everything", you can always open up a Konsole and type "sudo apt-get install lazarus".
But to be able to really recommend something specific, I'd have to know what you're developing.
There is "transparent" with regards to something "agnostic", which is like your "Transparent to the User". I can't define it particularly well, except by example: The POSIX filesystem API is storage-agnostic, which means that we can make accessing network shares transparent with regards to the filesystem API -- or we can implement a filesystem in RAM, and most of our programs would never know the difference (at least until we ran out of swap). The Linux block device API is device-agnostic, which means we can do transparent encryption -- that is, transparent to the filesystem, which just sees a block device.
This makes sense in that you can see through all the cogs whizzing around to see what you wanted to. It's not that the cogs are hidden, it's that you only see them if you look for them -- otherwise, you just see through to what you were really after. (My filesystem didn't want cyphertext, it wanted plaintext.)
There is also "transparent" as a contrast to an opaque (black) box. Instead, the mechanism is inside a transparent box, and you can see the cogs if you really want to. This is about open-ness -- open source, open standards, etc. The same is true for "money people".
I don't see a contradiction, though, as I look at both of these things as opposed to an opaque wall, preventing me from seeing what I want to. Transparency enables me to see what I want to see.
So, in that sense, perhaps there is a better metaphor, because transparency is a bit confusing when we try to compare it to a real-world object -- a "transparent" steering system means that you turn the steering wheel, and your wheels turn, without you having to know what happens under the hood. But a "transparent" hood means you do see everything under it. A well-designed car should allow for both -- I shouldn't have to look under the hood, but if I do, there should be labels and possibly diagrams, and I should be able to change my own oil, etc.
Some businesses are.
I don't think Linux is the answer to absolutely everything. I do think that it's very relevant, and in many cases, even its price is worth considering.
A few off the top of my head -- the EEE PC and Amazon EC2. If Amazon had to pay a license for every copy of an OS they run, EC2 would be a lot more expensive -- and Asus didn't want to have half the price of the laptop be for the software.
Now, Windows has gotten better at most of the things on his list... but it is something to consider. What is Windows buying you? And what is it actually costing you?
It's often been said that, on the desktop, Linux has to beat Windows by a lot for it to be worth the switch, due to lack of application support and a (mostly gone) learning curve. The same is true of Windows on the server -- even if Windows is better than Linux, or any other Unix, is it better enough to justify the licensing fee?
(That's a long way of saying: I challenge Microsoft's TCO studies, and I think Linux does better. But it's not an absolute, by any means.)
If you are not going to even read my post, don't bother replying.
I will say this:
This one, it's possible I didn't make clear. It takes up 100% of one CPU, in an obscure bug involving me unplugging the soundcard, and plugging it back in. By closing it and re-opening it, the problem is eliminated -- no need to kill it, even. So we can stop talking about amarok -- unless your whole argument is going to be that we need three cores so that we can still work when two threads are stuck in infinite loops.
I'd say, if you have two threads stuck in an infinite loop, you have a bigger problem.
The rest of your post has descended into name-calling, arguments from authority, and a re-iteration of points I've addressed... all in the post you just replied to.
By the way, in case you were wondering, your "years of experience" get you exactly as much respect as it did this guy.
So what?
What is "integraged"?
Seriously, though, most games will scale down decently to a modern Intel graphics card.
Also, you seem to think that playing games is a "basic thing" -- you're obviously not the target market. That said, my brother did get Warcraft 3 running on his.
Wow... Are you really that stupid?
An iPod is a hard drive with a music player attached. So you could, I don't know, store files on it? Or play music from it?
What good is 60 gigs of space when most of Joe Consumer's biggest files are already on his iPod, anyway?
They either don't buy an EEE, or they put XP on it.
However, that barrier is dropping rapidly. Consider someone who travels around with PowerPoint presentations -- they're mostly going to work in OO, and this thing is smaller, more portable, and boots faster.
I know! Since they don't have to be portable, we can make them pretty big... just put them on top of someone's desk. I think I'll call it a "desk-top"!
Who mentioned using it as a primary machine, except you?
I'd suggest that clever answers to these riddles can help, especially if the interviewer isn't attached to a "right" answer.
For example: "How would you weigh a Boeing 747?" Obvious answer? "Call Boeing."
I would say, any candidate who doesn't at least try that should be gone. Somewhere on The Daily WTF is an article which explains it best -- I'll try to quote from memory: "Which would you rather have working for you? The guy who takes the plane down to the docks and puts it into some water-displacement apparatus? Or the guy who calls Boeing?"
I know that no matter which side of the table I'm on, any answer other than "Call Boeing" is severe NIH syndrome, and should tell me something about what the actual work will be like.
I beg to differ -- Webkit is actually pretty damned good, in terms of speed, stability, and compliance. About the only thing it lacks is universal support from webpages, but then, that used to be a problem for Firefox -- there's not a whole lot a browser can (or should!) do about sites that don't follow the standards.
I'm going to say IE. Whatever replaces HTML must work in IE, and it must do so without any fuss.
But that's only because I'm assuming we'd replace HTML with something like XHTML, which is (inexplicably) broken in IE.
PDF is no more or less "fully graphical" than HTML. In fact, if I remember right, PDF is based on PostScript, which is a Turing-complete language designed to format documents for printing -- sounds pretty textual to me.
Flash might be, but do you really want the Internet to be based around keyframe animations?
The difference is, HTML is designed for the Web.
PDF is designed for print. I'd much rather have a website which I can resize to any window I want, and let the text flow to fit, than a PDF document which has pages that are certain proportions, exactly, leaving huge margins and gaps between pages for no reason. PDFs certainly have their place, but the Web ain't it.
And I only say that because I don't know enough about the other capabilities of PDF to know if it can quite replace the Web as we have it -- plugins, javascript, video, etc.
Now consider Flash. Adobe certainly seems to want this to happen. AIR embeds a SQLite engine, a Webkit engine, and probably some other things as well, basically allowing you to develop a desktop app in HTML and Flash -- but since it's Webkit everywhere, you don't have to worry about browser compatibility. And Flash itself keeps getting more and more capabilities, though it still sucks for video, and still isn't hardware-accelerated at all in the browser window.
But it's really frightening that you want to replace HTML, an open standard that works just about everywhere, with Flash, a wholly proprietary system that is only relevant to this discussion because Adobe has seen fit to port it to enough platforms. I'm still waiting for my 64-bit Linux Flash, and I can't do a damned thing about it, other than contribute to reverse-engineering projects like Gnash.
And yes, I know you can get the SWF spec. You can get it under a license which forbids you from developing a player. Woo hoo.
Stop right there.
You want us to stop working on improving HTML engines, and start working on adding features that don't currently exist to PDF or Flash? And then write a browser around them?
Think about that for a minute. Do you really expect it to be easier that way?
HTML is easy to parse. It's even easy to render. It's broken HTML that's hard.
And XHTML would be even easier -- but again, there's that Internet Explorer problem. That, and most websites aren't ready, either.
Now, if your suggestion was to start over completely, I'd be all for it. There are many things I wish had been done differently. But that would take an order of magnitude more time and effort than your crazy-assed PDF and SWF ideas.
Benchmarks? Or did you have a vested interest?
Foxit is nice on Windows... or would be, if I could get it to install, and not crash Firefox, etc.
On OS X, there's Preview, and on Linux, I mostly use KPDF. Both are small and fast. Both have browser plugins -- at least I assume Preview does, it's been awhile.
I'm not really sure how "indirectly" spawning threads and "manipulating" them is really any different than simply giving extensions a threading API.
The real problem here is that we are trying to create a safe sandbox such that extensions can be reasonably portable and somewhat safe, and actual websites can behave like applications and be absolutely safe. Anytime we give the extensions more power, there's the potential to break extensions, or make the browser unstable, make it harder to write safe extensions, etc. Anytime we give web pages more power, there's all that and more.
And threads are very powerful and very tricky under the best of circumstances.
But again, nothing really special about threads. Just about anything else falls under the same umbrella. Anyone remember popup ads?
Because then I want to use them for something else. Like my OS caching files, or some other program. In the first case, Firefox is assuming it's more important than whatever files I'm looking at locally. In the second, Firefox is going to get swapped out, which slows things down quite a lot.
The sane way to do this might be to have Firefox limit itself to something sane -- and consistent, irrespective of RAM size -- and push the rest out to disk. If there's really so much RAM lying around, it won't kill Firefox to let the OS cache things as files. Not as ideal as, say, a global OS-managed HTTP cache, or even something like memcached, but it would mean the OS gets to choose what the RAM gets used for, which is a lot better than Firefox deciding for itself.
That said, last I heard, the RAM usage was from fragmentation, which is technically not a memory leak, but is a way to leak memory.
Oh, bullshit. You are ONE person. I've seen probably hundreds of comments about Firefox eating up tons of RAM after only a few hours or days of use. It may well work for you, but that just means you haven't hit the problem yet.
Not going to happen unless they were already decent. Not good, decent.
Let's take an example from my interview... How would you check that a string is a palindrome?
A clever programmer might do something like:
A programmer somewhat more concerned with efficiency might iterate over the string, character by character, comparing the first half with the second half.
A more thorough, correct programmer would do either of the above, but stick a
in front of it -- probably also strip out punctuation and spaces.
And then there are the WTF programmers, who will do something like:
Oh, and the above won't actually work as written, aside from being absurdly inefficient both in coding time and in runtime if it did work. The amount of effort it would take to mold someone who would actually write the above into a decent programmer is not worth it.
Compare that to someone who wrote the first example (sentence.reverse == sentence) -- remind them about whitespace, punctuation, and capitalization, and they'll be able to work it out.
Now, absolutely, if you can't do this stuff yourself, hire someone who can. That part is tricky, but the complaint of the original article was not that they didn't know how to find any good programmers (or even superstars), but that they couldn't find enough.
And absolutely, one "star programmer" is not as important as a team that works well together -- but a "star project manager" isn't a silver bullet either.
Same applies to your suggestion. Should I break out the "your idea will not work" form? (I'd check the "Nice try, but I don't think it would work", I suppose)
Great, thanks for proving my point.
Now, why the irrelevant insult about wasting time on Slashdot? Is it possible that you have no valid points left? Maybe you never did?
Why?
No, seriously, let's pretend that I didn't know that. Let's pretend that when I said "no significant difference", what I really meant was "No difference at all! Everyone should use OS processes!"
In fact, let's ignore the fact that these "full OS processes" on some platforms are faster than "OS threads" on other platforms. Let's not even bring up which platform is which.
What relevance does this possibly have to the current discussion?
Put it back in context. I know you can do it, I just don't know why it always takes five posts to force you to make the connection...
It matters very little whether we talk about the 130 or so processes that are running on my laptop now, or the 150 or so threads. Either way, they are using less than 10% of one core -- or, more likely, less than 5% of each. You suggested that background threads could actually add up to fill one core:
Have you retracted this position?
Because this means, at the current rate -- that is, assuming the kinds of background processes I currently run -- I would need 10 times as many running as I have now before they filled up a core. And that's on my laptop, which is slower.
In that context, the choice of threads vs processes is completely irrelevant. The programs are already written. And even assuming processes are ten times slower (which they aren't), that only further proves my point -- I'm running a pile of (according to you) inefficient background processes that still don't eat up a tenth of one core. Were they more efficient, it would just mean it would take me doing that much more than ten times as much as I do now before triple core buys me anything more than faster povray renders.
Do any of the articles you linked to make the above untrue? Do any of them prove that a typical desktop user gives a flying fuck how efficient the multitasking is, as long as it feels fast?
Or have you managed to prove yourself as even more of a clueless geek than I am?
Is it if we're talking about a derivative work, and no explicit claim of authorship was made?
If so, you better make damned sure the law specifies that it is about corporate IP.
I'd really rather be able to continue to make one-off Slashdot posts and know they are copyrighted, at least for a reasonable amount of time. I wouldn't mind putting them under a Creative Commons license, even the more BSD-ish one (attribution), but those all require copyright to be effective.
That's a requirement, but it's also a loophole. Disney hardly depends on Mickey Mouse to run, so if it gets too expensive, they can simply transfer it to an individual.
So no, I don't think this can really be made to work, without a reasonably long leading "free" copyright. Might also be nice to have a longer "attribution-only" copyright.