Hard to say, as you have mistated my original point. It is not that learning a task-specific API is always a bad idea, but that some of the Rails task-specific API makes things harder than they need be.
Ok, that I can agree with.
No one has clained that the choice is either pure framework API or code from scratch, but some frameworks (and Rails may be headed this way if it is not already there) so pull you into their idiomatic way of thinking that it hampers you in the long run.
I'm not certain I share your concerns here. I'm not on the dev list, but it seems to me that the core devs are pretty happy with the baic level of functionality that Rails currently provides. The authors seem to be pushing people toward using Gems when they push the boundaries of what should be in the core install. I can see your concerns about Prototype-- you can certainly make a reasonable argument that it should be a seperate project completely. At the same time, having it as a core part of the framework makes perfect sense from a marketing standpoint, and I see no real disadvantages to including it.
(I suggest people lurk on the Rails dev mailing list and read the questions that come up. Very often thay are request for some magic Rails command to perform what is in fact a trivial Ruby task, exepct that using straight Ruby would entail actually learning Ruby.)
This is true of any framework. The big difference with Rails is that you have a huge number of newbs all at once. Once those users become more comfortable with their environment, they'll stop posting those silly requests.
As far as Nitro and Wee, they both look like good projects, and there's lots of room in the Ruby world for other projects. In fact, Rails is probably the best thing that ever happened to either project. I guarantee you that the number of Ruby programmers in the world will at least double over the next year, largely because of the hype around Rails. And I'm sure many others will see the same issues with Rails that you do. They'll be happy with the Ruby, but not so much with Rails. Those users will look for other options and they will find Nitro & Wee.
Or, get this wacky idea: Just learn Ruby and code everything from scratch. Then you wouldn't need to learn anything else. And still get extra productivity.
Sure, straight ruby is in some ways more productive then straight PHP, but you will get nowhere near the productivity gain from straight ruby as you would with ruby/rails. Taking your theory to it's logical conclusion, you couldn't use any external libraries, since they all have their own quirks that you need to learn-- Learning sucks, you better just code your own.
It's increasingly become a kitchen sink framework (e.g. what's with all the JavaScript/DHTML macros? Why couple the client to the server?)
None of the Javascript stuff is in anyway required. You are absolutely welcome to ignore it completely, and other then slightly increasing the disk space that a Rails installation requires, you won't even know that it's there. But if you want to build a truly interactive site, you will need to include Javascript code somehow. Again, you can write your own, or you can use the pre-built libraries that greatly simplify the process. And in fact, this argument actually strongly counters your central theme that it's not cost effective to learn Rails, since you you get large portions of Javascript for free with your Rails knowledge.
In other words, your theory is absolute crap. You will ALWAYS have to trade off a learning curve for increased productivity. The real trick is maximizing the return on your time investment. Rails gives you a VERY high productivity gain for it's reasonably light learning curve. I'm sure you're right that there are things in Rails that could be done a better way. But that's also true of every framework. No one environment is right for everyone, or every project. If you don't want to use or learn Rails, fabulous. But your arguments against it are silly & misguided.
Serioulsy, an issue with Rails is that it is a DSL on top of Ruby; knowing Ruby isn't enough (or, for that matter, even largely required), you have to learn the quirks and idioms of Rails, which (surprise) requires a book.
Can you name an environment where that isn't true? Python, you also have to learn Zope. Java, you learn Hibernate (or whatever). Of course you could just learn PHP & code everything from scratch. Then you wouldn't need to learn anything else. Of course, you get orders of magnitude less productivity.
Rails is fairly easy to learn, but like any other platform, it does have a learning curve. But with Rails or any similar framework, the question to ask is whether the productivity gains the framework will provide outweigh the investment in learning it. With Rails, I can almost guarantee you that the answer is yes. It's certainly not right for every project, but for those that it's right for (many if not most web apps fall into its domain) it will give you huge productivity gains.
I recommend you watch the demo videos on the rails page to get a taste of what Rails does. For example, you can see an entire basic but functional blog application built, real-time, in about 30 minutes (the second "seeing is believing" video). Once you see that, if you want to proceed, I'd skip the online tutorials & spend the $22.50 on the beta book. The quality & depth of the book is outstanding & it will greatly speed your advance with the language. Rails is really easy & at the same time kind of difficult. It's loaded with magic that makes tedious things trivial to code, but sometimes it can be a little difficult to grasp exactly what's going on. The book makes getting that understanding alot easier. If you're working with Rails you absolutely won't regret the purchase.
Have you ever read a few chapters of a long book, and already known that it was going to be a great book? This is one of those books. Even in it's beta, electronic form, is better then many technical books that I have bought.
As for Rails itself, there's a resaon why so many smart people are fawning all over it. I STRONGLY recommend you try out Rails before you criticize. At least watch one of the demo videos on the homepage. Until you see it in action, you really can't really fathom how powerful it is. You're right, there are numerous other capable frameworks out there, but once you see Rails in action, I guarantee you'll be impressed. Maybe not enough to switch, but at least you'll understand what all of the excitement is about.
Yeah, and I'm sure that their budget was at least that of Honda's as well. Wait a minute! No, it wasn't!
Granted, the "better then Honda" bit was some minor hyperbole, but if you consider the time & budget involved, I'd have to say that this was QUITE impressive.
Besides, they didn't say "Ours is better", they said "We think ours is better". Those two extra words are all important. You are welcome to your own opinion, but, apparently their opinion differs from yours. Sometimes that will happen.
I agree with you that the movie studios aren't hurting, but I think you are greatly overestimating their profit margin on DVD sales. First, you are ignoring one of the big production costs-- making the movie. While many movies go to DVD already profitable, many don't make enough money in the theatres to pay for their production. Either way, though, there are royalties to pay to actors, directors, etc. In addition, most DVDs have extras that can add a substantial amount of overhead to the production costs.
Two other errors: While I don't know the actual costs to the store, I can tell you that the retail margin is a lot higher then you're suggesting. In bookstores, the retail markup (at SRP) is closer to 40% then 20%, and I assume that the same is true for DVDs. Finally, the film companies don't normally sell directly to resellers. They sell to distributors, who in turn sell to the retailers. I assume that their margins are slimmer then the retailers (they operate on much higher volumes), but they still need to make a profit.
I suspect that a more realistic breakdown is that a DVD that retails for $15 costs the retailer about $9, and it costs the distributor about $7. Subtract the $2 manufacturing cost, and probably $1 for shipping, handling & overhead, and you're down to about $4 per DVD before paying anything for the actual content.
Don't get me wrong... I'm not defending the MPAA. But it's silly to think that 80% (or even 40%) of that 27.5 billion is profit.They make a hefty profit, but not quit that hefty.
$350 = about 35 cheap keyboards. Assuming your mom is the worst klutz in the world & a terrible house keeper to boot, she could -still- probably get 2 months per keyboard. Worst case, you'd go three years before justifying the purchase, and in reality most people will easily get 6 months or more out of a $10 keyboard. RSI won't be a significant concern for a kitchen system-- it's not like your going to be writing novels on it.
For a kitchen computer, I'd go with a Shuttle system, which gives you a good compromise between price & power, size & expandability. A Mac Mini would work, but you couldn't add a TV adapter (though most likely a USB one would work fine). Either way, add a 15-17" -non-touchscreen- LCD, keyboard, mouse & TV adapter and you should be under $800 for a good system. It seems silly to spend $350 on a keyboard for a $800 system.
Ya got to wonder about the idiots who set the prices on these things. This could be a successful product if they sold it for aroung $800 or so. Instead, they sell it for $2300 & they wonder why nobody wants one...
I agree with most of what you say. Touchscreens are OK, but they are expensive. Be sure to wash & dry your hands thouroughly before scrolling the page so you can see how much butter to add to your recipe. You forgot? No problem, a replacement monitor is only $600. You can buy an optical mouse for $10. Even if you have to buy a new one every 3 months, it would be years before you've paid the premium on you -first- TS monitor, let alone a replacement. Fry's had a 17" LCD for $200 last weekend. You get a larger display, and save $400.
For the same reason, though, I disagree with your suggestion of a wireless keyboard/mouse combo. For this application, get a cheap $10-15 keyboard. If you can find one to fit your keyboard, a "keyboard condom" will help protect against spills. But since the keyboard is cheap, so even if it gets ruined, your not out much. And definitely don't buy a trackball. Your hands will be dirty and/or wet when you use it. While a decent trackball should be alright for a while under these conditions, even a cheap mouse should be able to take a fair amnunt of abuse before giving out.
This is not a very good idea for this particular application. Sure it's small, which makes installation easy, but that same advantage becomes a disadvantage as soon as your eyesight starts to go. Most modern websites use designs that require relatively wide displays-- usually at least 800x600. On a 7" display, that means VERY tiny pixels. Since the specified application is a kitchen computer for browsing recipes & watching TV for the posters parents, a 7" display is basically useless.
For pete's sake, can we leave the blatant advertising in the ad windows and such where we can ignore them if we choose?
This is a product announcement, yes. But it is an announcement for a product that a very large percentage of/. readers will be interested in. If you aren't, just skip to the next article. No one is forcing you to click the read more link. There are plenty more stories out there, so if you don't want to read this one, feel free to ignore it.
Thank you. I was going to say exactly the same thing, but you beat me to it... BTW, love the sig.
Re:If this were Trek...
on
Bayesian Tail
·
· Score: 1
That said, I don't buy logfile filtering until I see it works. Sometimes you are interested in messages of one kind, sometimes in messages of another kind. I still think that fixed pattern matching can do the job better. Of course, that's what many people feel about spam filtering.
I think you're misinterpreting what the tool is meant for. Often, when you are looking at the logs, you are looking for something in particular. In those cases, as you suggest, grep is probably the best tool for the job. But, as far as I can tell, btail is not meant for that. Instead, btail is intended as a tool to allow periodic monitoring of the system. It filters out all of the routine stuff, but passes through anything important or out of the ordinary. For this purpose, grep is pretty much useless. Like in most parts of life, choose the best tool for the job. Sometimes it will be grep, but for its intended purpose, btail will make things much easier.
So, you're saying apps should all handle their own focus management, possibly in different ways, possibly broken or buggy in different ways.
No, that's not what I'm suggesting. I agree with you that the OS (or window manager in the case of X Windows) should handle this. Apparently, however, they don't. Since that is the case, the developers seem to have three choices... Either put up with constant complaints from annoyed users, switch to an MDI-like interface, or, unfortunately, manage their non-file windows themselves.
BTW, this obviously IS possible. I normally use Firefox, but I know that Konqueror has the ability to float it's toolbars. The floated toolbars don't show up in the taskbar, and they are automatically moved forward & back with the parent window. I thought that the problem with GIMP might be that I was running it under KDE, but switching over to Gnome, I see that the issues are the same there. Konq, also works the same was as it does under KDE-- the tolbars don't show up on the taskbar. Assuming Konq manages it's own windows, perhaps this implementation is less then ideal. But from the point of view of a user, I couldn't care less-- it works the way I want and expect.
So, is the best way to handle the problem to do it in the app? No. In an ideal OS, the WM would handle this for you. But barring that, it would seem that the developers have no good choice but to do it themselves. The only other option-- not doing it & forcing the user to manage the windows manually-- only seems like a good option to the developers.
Also, focus policy has nothing to do with the issue. Handled properly, the tool windows follow the file windows. If you have a "focus follows mouse" policy, pointing at the file window brings the file window, and the relevant tool windows, to the front. If you point at a tool window in an application that has more then one file open, the last accessed file would be brought to the front. Everything would be the same with a "focus on click" policy, except that you would have to click on the window. This is the way it works in virtually every other OS, and it is the way the user expects. I'm all for trying other paradigms for user interaction, but only when there is at least some user benefit to the proposed change. Changing simply because the developers have "moral" objections to the other option is silly.
FYI, see the discussion at http://www.scalzi.com/whatever/003093.html for a discussion of the ACLU & Christianity. There are several good points, but in particular, see the comment by Casey Holland, about 1/4 of the way doown the page. It starts "I'm only a lowly 2nd year law student at the University of Kentucky, but I fit the rest of the bill".
Also see the page http://linkfilter.net/?id=68847 which contains several links to stories where the ACLU defended Christian groups.
I realize that it's grossly oversimplistic to imply that Christianity=right wing, but the right does so all the time. In this case, I think that demonstrating that the ACLU defends Christian rights clearly demonstrates that labeling the ACLU as a leftist group is blatant political fearmongering.
But that's a matter for the window manager - would be nice if that gets implemented in metacity or kwin or sawfish, or whatever floats your boat. But just because some functionality is missing in the WM, doesn't mean you should implement it in the wrong place - the applications.
So are you saying that an application running under a typical window manager doesn't know when it has focus? I'm not a programmer, but it seems that as long as the application knows it is focused, it should be trivial to bring the other windows to the front, shouldn't it? This is a feauture that the Mac has had for most of it's existence... I find it flabbergasting that you are suggesting that X-Windows lacks this ability.
It's also relatively trivial in most WMs to make those floating windows always-on-toppish like the PS ones (only more flexible).
Always on top is not equivalent or remotely more flexible then traditional tool windows. The non-file windows should ONLY be active if a file window is, and then they should automatically activated. Always on top means just that-- The windows are ALWAYS on top. Since modern operating systems allow more then one application to be open at a time, there may be times when I don't want them on top. And, yes, I can move my GIMP windows to a seperate desktop, but that's not an acceptable answer. Any application that requires me to change my work style to overcome it's shortcomings is badly designed. This should be an easy thing to fix, and I have yet to hear even a single benefit to the current design. If there is one, I would be happy to hear it.
The guy claimed to have the movies available on his website. In order for the MPAA to check whether or not he was lying (as it turns out he was), they'd have to have paid the guy money to sign up for hihs "service". That's probably why they didn't bother.
I agree with much of what you have to say, but here I disagree. You should have some proof of wrongdoing before you sue. Just because the guy claimed to be offering the movie for download isn't enough. The fact that at least one of the movies wasn't even completed yet casts serious doubts as to the veracity of his claims. Based on the alone, they should have investigated further. I think $3 is not an unreasonable amount to verify the claims. If he was in fact offering the movies for download, they could easily ask for an extra $3 in damages. The fact that they couldn't be bothered to verify his (easily verifiable) claims makes this a reasonable lawsuit.
Why does it belong on the front page, because the lawyer is throwing around the phrase "first amendment"?
Here you're wrong as well. Assuming that he was not violating the law, this is a significant first ammendment issue. The MPAA can't stifle his right to free speech on the off chance that he might be violating the law. If he is, then they have every right to go after him. But they must first have evidence to back up their claims. Had they paid the $3, the case could have been a slam dunk.
One thing that we do know is that the MPAA committed perjury: "The MPAA stated, under penalty of perjury, that in 2001 www.InternetMovies.com made available for illegal download the third installment of "The Lord of the Rings", which was not actually finished until 2003." So, it seems to me that the one side that can conclusively be proven to have broken the law is the MPAA. Let's hope the courts are awake enough to realize that.
I suppose you have me there. I guess I should have said "application", not program...
There are a number of changes that could be made, many of which are almost trivial. The first thing that I would change is to make the floating tool windows automatically come to the front if any of the image windows are selected. This is the way it works on MacOS, and it's a simple fix to the single most annoying feature of the Gimp. I understand the distaste for MDI apps, but having to manually activate each window everytime you switch from another app back to Gimp is a pain. I know, I can put all my Gimp windows on another desktop, but that's not what I do by habit. An application shouldn't force me to change the way that I work just to overcome it's shortcomings. If this can't be done without switching to a MDI, then it's worth switching, or at least making this a user preference. If you can come up with any reason why the current behavior is preferable, I'd love to hear it.
True, you can never please all of the people all of the time, but there are good interfaces and bad interfaces. While you may not like the iPod, most people love it. Gimp is the opposite--a few people love it (mostly the developers), everyone else finds it completely unusable. I have never heard of a program that is as universally criticized as having a bad interface, but the developers completly ignore the critiques. Gimp is powerful, but it is needlessly hard to use.
Sure there's something to be said for coming up with a new, more powerful interface-- but only if it's usable. The argument that "people just aren't used to it yet" doesn't fly. The users of Gimp are by definition, some of the most advanced computer users around. If they can't figure it out, normal users never will.
Until the usability problems are fixed, it will never be used by more then a few geeks.
As far as I know, accounts are not automatically classified as commericial. According to the site "Personal accounts can send payments to and receive payments from, anyone with an email address. Business accounts can send and receive payments, and also accept credit card payments." I believe there are other benefits to a commercial account, such as automatic nightly deposits to a bank account, but if you don't need those features, you can stick with a personal account.
most of my friends want my mp3's because even the loq quality 192 fixed bitrates aound better than their best VBR rips in windows.
Tell them about CDex. It also uses LAME, so the Mp3 quality should be comparable. It doesn't use Paranoia, so the final quality could be a bit less (or more then a bit on heavily damaged discs), but I have had few real complaints. Oh, yeah, it's also Free & Open Source.
Slashdot Mirror
Hard to say, as you have mistated my original point. It is not that learning a task-specific API is always a bad idea, but that some of the Rails task-specific API makes things harder than they need be.
Ok, that I can agree with.
No one has clained that the choice is either pure framework API or code from scratch, but some frameworks (and Rails may be headed this way if it is not already there) so pull you into their idiomatic way of thinking that it hampers you in the long run.
I'm not certain I share your concerns here. I'm not on the dev list, but it seems to me that the core devs are pretty happy with the baic level of functionality that Rails currently provides. The authors seem to be pushing people toward using Gems when they push the boundaries of what should be in the core install. I can see your concerns about Prototype-- you can certainly make a reasonable argument that it should be a seperate project completely. At the same time, having it as a core part of the framework makes perfect sense from a marketing standpoint, and I see no real disadvantages to including it.
(I suggest people lurk on the Rails dev mailing list and read the questions that come up. Very often thay are request for some magic Rails command to perform what is in fact a trivial Ruby task, exepct that using straight Ruby would entail actually learning Ruby.)
This is true of any framework. The big difference with Rails is that you have a huge number of newbs all at once. Once those users become more comfortable with their environment, they'll stop posting those silly requests.
As far as Nitro and Wee, they both look like good projects, and there's lots of room in the Ruby world for other projects. In fact, Rails is probably the best thing that ever happened to either project. I guarantee you that the number of Ruby programmers in the world will at least double over the next year, largely because of the hype around Rails. And I'm sure many others will see the same issues with Rails that you do. They'll be happy with the Ruby, but not so much with Rails. Those users will look for other options and they will find Nitro & Wee.
Or, get this wacky idea: Just learn Ruby and code everything from scratch. Then you wouldn't need to learn anything else. And still get extra productivity.
Sure, straight ruby is in some ways more productive then straight PHP, but you will get nowhere near the productivity gain from straight ruby as you would with ruby/rails. Taking your theory to it's logical conclusion, you couldn't use any external libraries, since they all have their own quirks that you need to learn-- Learning sucks, you better just code your own.
It's increasingly become a kitchen sink framework (e.g. what's with all the JavaScript/DHTML macros? Why couple the client to the server?)
None of the Javascript stuff is in anyway required. You are absolutely welcome to ignore it completely, and other then slightly increasing the disk space that a Rails installation requires, you won't even know that it's there. But if you want to build a truly interactive site, you will need to include Javascript code somehow. Again, you can write your own, or you can use the pre-built libraries that greatly simplify the process. And in fact, this argument actually strongly counters your central theme that it's not cost effective to learn Rails, since you you get large portions of Javascript for free with your Rails knowledge.
In other words, your theory is absolute crap. You will ALWAYS have to trade off a learning curve for increased productivity. The real trick is maximizing the return on your time investment. Rails gives you a VERY high productivity gain for it's reasonably light learning curve. I'm sure you're right that there are things in Rails that could be done a better way. But that's also true of every framework. No one environment is right for everyone, or every project. If you don't want to use or learn Rails, fabulous. But your arguments against it are silly & misguided.
Serioulsy, an issue with Rails is that it is a DSL on top of Ruby; knowing Ruby isn't enough (or, for that matter, even largely required), you have to learn the quirks and idioms of Rails, which (surprise) requires a book.
Can you name an environment where that isn't true? Python, you also have to learn Zope. Java, you learn Hibernate (or whatever). Of course you could just learn PHP & code everything from scratch. Then you wouldn't need to learn anything else. Of course, you get orders of magnitude less productivity.
Rails is fairly easy to learn, but like any other platform, it does have a learning curve. But with Rails or any similar framework, the question to ask is whether the productivity gains the framework will provide outweigh the investment in learning it. With Rails, I can almost guarantee you that the answer is yes. It's certainly not right for every project, but for those that it's right for (many if not most web apps fall into its domain) it will give you huge productivity gains.
I recommend you watch the demo videos on the rails page to get a taste of what Rails does. For example, you can see an entire basic but functional blog application built, real-time, in about 30 minutes (the second "seeing is believing" video). Once you see that, if you want to proceed, I'd skip the online tutorials & spend the $22.50 on the beta book. The quality & depth of the book is outstanding & it will greatly speed your advance with the language. Rails is really easy & at the same time kind of difficult. It's loaded with magic that makes tedious things trivial to code, but sometimes it can be a little difficult to grasp exactly what's going on. The book makes getting that understanding alot easier. If you're working with Rails you absolutely won't regret the purchase.
Have you ever read a few chapters of a long book, and already known that it was going to be a great book? This is one of those books. Even in it's beta, electronic form, is better then many technical books that I have bought.
As for Rails itself, there's a resaon why so many smart people are fawning all over it. I STRONGLY recommend you try out Rails before you criticize. At least watch one of the demo videos on the homepage. Until you see it in action, you really can't really fathom how powerful it is. You're right, there are numerous other capable frameworks out there, but once you see Rails in action, I guarantee you'll be impressed. Maybe not enough to switch, but at least you'll understand what all of the excitement is about.
Yeah, and I'm sure that their budget was at least that of Honda's as well. Wait a minute! No, it wasn't!
Granted, the "better then Honda" bit was some minor hyperbole, but if you consider the time & budget involved, I'd have to say that this was QUITE impressive.
Besides, they didn't say "Ours is better", they said "We think ours is better". Those two extra words are all important. You are welcome to your own opinion, but, apparently their opinion differs from yours. Sometimes that will happen.
I agree with you that the movie studios aren't hurting, but I think you are greatly overestimating their profit margin on DVD sales. First, you are ignoring one of the big production costs-- making the movie. While many movies go to DVD already profitable, many don't make enough money in the theatres to pay for their production. Either way, though, there are royalties to pay to actors, directors, etc. In addition, most DVDs have extras that can add a substantial amount of overhead to the production costs.
Two other errors: While I don't know the actual costs to the store, I can tell you that the retail margin is a lot higher then you're suggesting. In bookstores, the retail markup (at SRP) is closer to 40% then 20%, and I assume that the same is true for DVDs. Finally, the film companies don't normally sell directly to resellers. They sell to distributors, who in turn sell to the retailers. I assume that their margins are slimmer then the retailers (they operate on much higher volumes), but they still need to make a profit.
I suspect that a more realistic breakdown is that a DVD that retails for $15 costs the retailer about $9, and it costs the distributor about $7. Subtract the $2 manufacturing cost, and probably $1 for shipping, handling & overhead, and you're down to about $4 per DVD before paying anything for the actual content.
Don't get me wrong... I'm not defending the MPAA. But it's silly to think that 80% (or even 40%) of that 27.5 billion is profit.They make a hefty profit, but not quit that hefty.
$350 = about 35 cheap keyboards. Assuming your mom is the worst klutz in the world & a terrible house keeper to boot, she could -still- probably get 2 months per keyboard. Worst case, you'd go three years before justifying the purchase, and in reality most people will easily get 6 months or more out of a $10 keyboard. RSI won't be a significant concern for a kitchen system-- it's not like your going to be writing novels on it.
For a kitchen computer, I'd go with a Shuttle system, which gives you a good compromise between price & power, size & expandability. A Mac Mini would work, but you couldn't add a TV adapter (though most likely a USB one would work fine). Either way, add a 15-17" -non-touchscreen- LCD, keyboard, mouse & TV adapter and you should be under $800 for a good system. It seems silly to spend $350 on a keyboard for a $800 system.
Ya got to wonder about the idiots who set the prices on these things. This could be a successful product if they sold it for aroung $800 or so. Instead, they sell it for $2300 & they wonder why nobody wants one...
I agree with most of what you say. Touchscreens are OK, but they are expensive. Be sure to wash & dry your hands thouroughly before scrolling the page so you can see how much butter to add to your recipe. You forgot? No problem, a replacement monitor is only $600. You can buy an optical mouse for $10. Even if you have to buy a new one every 3 months, it would be years before you've paid the premium on you -first- TS monitor, let alone a replacement. Fry's had a 17" LCD for $200 last weekend. You get a larger display, and save $400.
For the same reason, though, I disagree with your suggestion of a wireless keyboard/mouse combo. For this application, get a cheap $10-15 keyboard. If you can find one to fit your keyboard, a "keyboard condom" will help protect against spills. But since the keyboard is cheap, so even if it gets ruined, your not out much. And definitely don't buy a trackball. Your hands will be dirty and/or wet when you use it. While a decent trackball should be alright for a while under these conditions, even a cheap mouse should be able to take a fair amnunt of abuse before giving out.
This is not a very good idea for this particular application. Sure it's small, which makes installation easy, but that same advantage becomes a disadvantage as soon as your eyesight starts to go. Most modern websites use designs that require relatively wide displays-- usually at least 800x600. On a 7" display, that means VERY tiny pixels. Since the specified application is a kitchen computer for browsing recipes & watching TV for the posters parents, a 7" display is basically useless.
AC parent should be modded up...
For pete's sake, can we leave the blatant advertising in the ad windows and such where we can ignore them if we choose?
/. readers will be interested in. If you aren't, just skip to the next article. No one is forcing you to click the read more link. There are plenty more stories out there, so if you don't want to read this one, feel free to ignore it.
This is a product announcement, yes. But it is an announcement for a product that a very large percentage of
Thank you. I was going to say exactly the same thing, but you beat me to it... BTW, love the sig.
That said, I don't buy logfile filtering until I see it works. Sometimes you are interested in messages of one kind, sometimes in messages of another kind. I still think that fixed pattern matching can do the job better. Of course, that's what many people feel about spam filtering.
I think you're misinterpreting what the tool is meant for. Often, when you are looking at the logs, you are looking for something in particular. In those cases, as you suggest, grep is probably the best tool for the job. But, as far as I can tell, btail is not meant for that. Instead, btail is intended as a tool to allow periodic monitoring of the system. It filters out all of the routine stuff, but passes through anything important or out of the ordinary. For this purpose, grep is pretty much useless. Like in most parts of life, choose the best tool for the job. Sometimes it will be grep, but for its intended purpose, btail will make things much easier.
So, you're saying apps should all handle their own focus management,
possibly in different ways, possibly broken or buggy in different ways.
No, that's not what I'm suggesting. I agree with you that the OS (or window manager in the case of X Windows) should handle this. Apparently, however, they don't. Since that is the case, the developers seem to have three choices... Either put up with constant complaints from annoyed users, switch to an MDI-like interface, or, unfortunately, manage their non-file windows themselves.
BTW, this obviously IS possible. I normally use Firefox, but I know that Konqueror has the ability to float it's toolbars. The floated toolbars don't show up in the taskbar, and they are automatically moved forward & back with the parent window. I thought that the problem with GIMP might be that I was running it under KDE, but switching over to Gnome, I see that the issues are the same there. Konq, also works the same was as it does under KDE-- the tolbars don't show up on the taskbar. Assuming Konq manages it's own windows, perhaps this implementation is less then ideal. But from the point of view of a user, I couldn't care less-- it works the way I want and expect.
So, is the best way to handle the problem to do it in the app? No. In an ideal OS, the WM would handle this for you. But barring that, it would seem that the developers have no good choice but to do it themselves. The only other option-- not doing it & forcing the user to manage the windows manually-- only seems like a good option to the developers.
Also, focus policy has nothing to do with the issue. Handled properly, the tool windows follow the file windows. If you have a "focus follows mouse" policy, pointing at the file window brings the file window, and the relevant tool windows, to the front. If you point at a tool window in an application that has more then one file open, the last accessed file would be brought to the front. Everything would be the same with a "focus on click" policy, except that you would have to click on the window. This is the way it works in virtually every other OS, and it is the way the user expects. I'm all for trying other paradigms for user interaction, but only when there is at least some user benefit to the proposed change. Changing simply because the developers have "moral" objections to the other option is silly.
FYI, see the discussion at http://www.scalzi.com/whatever/003093.html for a discussion of the ACLU & Christianity. There are several good points, but in particular, see the comment by Casey Holland, about 1/4 of the way doown the page. It starts "I'm only a lowly 2nd year law student at the University of Kentucky, but I fit the rest of the bill".
Also see the page http://linkfilter.net/?id=68847 which contains several links to stories where the ACLU defended Christian groups.
I realize that it's grossly oversimplistic to imply that Christianity=right wing, but the right does so all the time. In this case, I think that demonstrating that the ACLU defends Christian rights clearly demonstrates that labeling the ACLU as a leftist group is blatant political fearmongering.
But that's a matter for the window manager - would be nice if that gets implemented in metacity or kwin or sawfish, or whatever floats your boat. But just because some functionality is missing in the WM, doesn't mean you should implement it in the wrong place - the applications.
So are you saying that an application running under a typical window manager doesn't know when it has focus? I'm not a programmer, but it seems that as long as the application knows it is focused, it should be trivial to bring the other windows to the front, shouldn't it? This is a feauture that the Mac has had for most of it's existence... I find it flabbergasting that you are suggesting that X-Windows lacks this ability.
It's also relatively trivial in most WMs to make those floating windows always-on-toppish like the PS ones (only more flexible).
Always on top is not equivalent or remotely more flexible then traditional tool windows. The non-file windows should ONLY be active if a file window is, and then they should automatically activated. Always on top means just that-- The windows are ALWAYS on top. Since modern operating systems allow more then one application to be open at a time, there may be times when I don't want them on top. And, yes, I can move my GIMP windows to a seperate desktop, but that's not an acceptable answer. Any application that requires me to change my work style to overcome it's shortcomings is badly designed. This should be an easy thing to fix, and I have yet to hear even a single benefit to the current design. If there is one, I would be happy to hear it.
The guy claimed to have the movies available on his website. In order for the MPAA to check whether or not he was lying (as it turns out he was), they'd have to have paid the guy money to sign up for hihs "service". That's probably why they didn't bother.
I agree with much of what you have to say, but here I disagree. You should have some proof of wrongdoing before you sue. Just because the guy claimed to be offering the movie for download isn't enough. The fact that at least one of the movies wasn't even completed yet casts serious doubts as to the veracity of his claims. Based on the alone, they should have investigated further. I think $3 is not an unreasonable amount to verify the claims. If he was in fact offering the movies for download, they could easily ask for an extra $3 in damages. The fact that they couldn't be bothered to verify his (easily verifiable) claims makes this a reasonable lawsuit.
Why does it belong on the front page, because the lawyer is throwing around the phrase "first amendment"?
Here you're wrong as well. Assuming that he was not violating the law, this is a significant first ammendment issue. The MPAA can't stifle his right to free speech on the off chance that he might be violating the law. If he is, then they have every right to go after him. But they must first have evidence to back up their claims. Had they paid the $3, the case could have been a slam dunk.
One thing that we do know is that the MPAA committed perjury: "The MPAA stated, under penalty of perjury, that in 2001 www.InternetMovies.com made available for illegal download the third installment of "The Lord of the Rings", which was not actually finished until 2003." So, it seems to me that the one side that can conclusively be proven to have broken the law is the MPAA. Let's hope the courts are awake enough to realize that.
ed?
I suppose you have me there. I guess I should have said "application", not program...
There are a number of changes that could be made, many of which are almost trivial. The first thing that I would change is to make the floating tool windows automatically come to the front if any of the image windows are selected. This is the way it works on MacOS, and it's a simple fix to the single most annoying feature of the Gimp. I understand the distaste for MDI apps, but having to manually activate each window everytime you switch from another app back to Gimp is a pain. I know, I can put all my Gimp windows on another desktop, but that's not what I do by habit. An application shouldn't force me to change the way that I work just to overcome it's shortcomings. If this can't be done without switching to a MDI, then it's worth switching, or at least making this a user preference. If you can come up with any reason why the current behavior is preferable, I'd love to hear it.
Key word is MOSTLY... You might want to look it up.
True, you can never please all of the people all of the time, but there are good interfaces and bad interfaces. While you may not like the iPod, most people love it. Gimp is the opposite--a few people love it (mostly the developers), everyone else finds it completely unusable. I have never heard of a program that is as universally criticized as having a bad interface, but the developers completly ignore the critiques. Gimp is powerful, but it is needlessly hard to use.
Sure there's something to be said for coming up with a new, more powerful interface-- but only if it's usable. The argument that "people just aren't used to it yet" doesn't fly. The users of Gimp are by definition, some of the most advanced computer users around. If they can't figure it out, normal users never will.
Until the usability problems are fixed, it will never be used by more then a few geeks.
As far as I know, accounts are not automatically classified as commericial. According to the site "Personal accounts can send payments to and receive payments from, anyone with an email address. Business accounts can send and receive payments, and also accept credit card payments." I believe there are other benefits to a commercial account, such as automatic nightly deposits to a bank account, but if you don't need those features, you can stick with a personal account.
most of my friends want my mp3's because even the loq quality 192 fixed bitrates aound better than their best VBR rips in windows.
Tell them about CDex. It also uses LAME, so the Mp3 quality should be comparable. It doesn't use Paranoia, so the final quality could be a bit less (or more then a bit on heavily damaged discs), but I have had few real complaints. Oh, yeah, it's also Free & Open Source.