Not a friend of mine, just a good link I'd found before that actually detailed what's wrong Bose. I agree that right-click disabling is the most annoying thing ever (and useless -- View->Source in IE gets you the frameset source, which tells you the frame page, where you can again View->Source and get the source). I'll paste the contents of the page as an AC below this thread, so you can read them.
What about my RF bose remote? Neither of the products (or any other remote AFAIK) support bose systems. I think the pronto mentioned rf functionality, but that is only with it's own base unit (for emulating rf with ir products). Does anyone know of a remote that is compatible with bose systems?
The products don't support Bose with good reason. These remotes are meant for relatively high-end or better mid-level systems, which Bose isn't.
EVERY single one of them deteriorated to the point where they were useless.
Same here. I had several problems with my old Deskjet 500. The least trivial was a bad power cord. It developed a short early in its lifetime, and ever after would kill power at the slightest bump and required contortions to get power in the first place. Easily replaceable, but not when you're a college student on a budget using a hand-me-down printer. The second problems was more painful, and more expensive to fix (to the point where it was cheaper to buy a new printer). The paper feed mechanism wore down (it was a friction feed, like most printers are) and would misfeed paper at the most inopportune times. Ten pages into a twenty page paper, the printer would decide to feed five pieces of paper into the tray rather than one. Worse, sometimes it would skew the paper, or even stop feeding at all (your printed page ended up being jumbled into a single line -- try handing that in!).
I "fixed" this by switching to LyX (because I didn't want to learn TeX/LaTeX syntax, and because Word kept screwing up footnotes by misnumbering them or putting them on the wrong page) for use on our engineering workstations (Suns, IBMs, and HPs), and printing with my 500 page laser printer quota (free printing! You couldn't print more than 500 pages per semester, and your balance didn't roll over by semester, but it was more than sufficient and better than going to the campus-wide non-engineering labs and paying for printer use).
Most of the noise about Linux being a platform for world domination is just that, noise. If you have a complaint, either fix it or find another solution.
I don't give a crap about the "Wurld Domeenashun" crowd. It's the Redhats and IBMs that are driving Linux as a platform (and not as a kernel) towards wider acceptance on the server and on the workstation. Your "fix it or go away" mindset is what's working against these companies trying to get wider mindshare for Linux. For every IBM out there, there are literally thousands of you. The odds are against them, and that's a problem. For me, I've found another platform. I don't use Linux on the desktop, and won't be any time soon. As well, I don't do Linux development (unless you count the small bit of php I do for my personal site) because of the issues I raised above. I won't be doing any Linux programming, either, until a majority of the problems I brought up are satisfactorily solved (effectively, that means it's highly unlikely I'll ever do any professional Linux programming, or even widely-distributed personal projects). I'm not in a position where I can effect those changes, so your "put up or shut up" argument carries no weight.
About "pick one": there is no point in that; I use them all concurrently without problems.
You missed the point. I don't care that you can use them all concurrently. I want to be guaranteed that the widget set I target will be on the users system without me having to distribute it, and without them having to do anything extra. Thus, pick one or two, and have every distro include them.
About compiling gnome by hand: What kind of a fool does it take to want to do this? Compiling should be restricted to applications (not libraries!) which aren't covered by the distributions.
See the discussion about short-comings and incompatibilities among package managers. GNOME was an example, but it can apply to applications as well -- if my application uses libraries you don't have, then you need to get those libraries before you can use my application. I could distribute those libraries (bad idea), or I could reinvent the wheel once again to remove the dependency (another bad idea). The proper solution is to standardize on some set of libraries for common functions that would guarantee that my application has what it needs (note: esoteric libraries are the exception -- I'm fine taking a dependency on something like a high-level mathematics library, because I don't expect every system to have that. I am not willing to take a dependency on some ui widget set because that should be standard across distros. I don't want to have to worry about whether or not my users have GTK, QT, or if they've only installed TK and nothing more).
Is it moral for a government to stand idly by and allow the small business firm get crushed by legal action by the larger fish with more cash than they know what to do with? We've got lots of reports of incidents lying around slashdot's archives especially if you add the word "Microsoft" to the oppressor list (Lindows ring a recent bell to anyone?). Isn't a (to continue the metaphor) safe reef needed?
This one is fairly easy if you subscribe to free market economics (if you're into socialism or communism, the answer is still easy, but it's the opposite...). First, let's get the "legal action" issue sorted out. Microsoft rarely uses legal action (no, really, check it out. Microsoft is usually on the receiving end, not the giving end). You misrepresent the Lindows suit. That was over a name. All Lindows had to do was change their name, and they could continue to do business (and IMHO, the lawsuit was justified because the name was intentionally chosen to be similar to a Microsoft product which it was aiming at replacing -- if Microsoft change the name of SQL Server to Boracle, or changed Windows to Wolaris, everybody here would be up in arms, but because Lindows is a Linux company and an underdog, they don't get any flak for the name they chose...).
So, assuming that the largest of the large companies tend not to use legal actions, let's throw that out and look at economic factors. Sure, Microsoft is a monopoly in the operating system arena (being a monopoly is not illegal, but abusing the position is). However, except in the very extreme case of a corporation abusing its monopoly power (Standard Oil, but not IBM, and not Microsoft to some extent), the government should step out and let the market control itself. Yes, there are issues with a free market economy having cyclic highs and lows, but the government can lessen the impact of those almost totally through the manipulation of interest rates and nothing more. If a smaller company cannot compete with a larger one, then the market decided.
9 out of every 10 businesses (warning! I made up the numbers, but the ratio is really that high) go under. The upside is that every day people create new businesses. In most markets, when one business goes under there are several others ready to step in and take its place (alternatively, that business was in a market that didn't exist, like a lot of dot-com companies -- when the bubble burst, they went away and nobody replaced them because the markets they were in were largely fictional).
Besides, if he wants to look 'current' he should focus on the ethical questions about.net
Interesting. Could you expand please? What ethical questions exist around.NET that wouldn't exist around any other development architecture? Are you referring to Microsoft's Shared Source program and their Shared Source implementation of the ECMA standard in Rotor? Or how about Microsoft submitting only portions of their.NET platform for ECMA standardization, and whether or not those portions are useful as a complete system (without a database layer, ui layer, etc)? How does that compare with Sun, who will not submit even a portion of the Java platform to a standardization body? You were probably just being facetious, but this could be an interesting ethical area to explore.
Perhaps you mean to say that current IDEs suck? What's stopping an IDE from integrating autotools support? I'd use it. I don't know how to use autoconf/automake (more from lack of caring than anything), but I think if an IDE made it easy for me, I would. As well, why does an IDE need to support autotools? There's no reason why you need to compile within an IDE. I spend probably 95% of my programming time writing code in an IDE but compiling it from the commandline. I don't use the IDE to compile, but I'm not going to switch to notepad because I like all the extra features I get from the various IDEs I like.
Don't give me the "X86" only thing because there are now probably 10-15 somewhat incompatible varieties of X86.
And unless you're writing assembly code, you're never (well, 99.5% of the time) going to see any of those differences. The compiler should take care of those small differences.
For Debian at least, you can use GNOME, KDE, GTK, whatever you want because the package will pull in all the required libs when you go to install it. It's a no-brainer for the user, and not much more work for the developer either.
And now you've got a debian-only distributable. People cry foul when someone like Oracle (for example) releases their product only for Redhat, but that's what developers are forced to do. Distributions are just too different for a developer to support more than one or two of them. I know there's the FSH, but filesystem standards aren't enough. Linux needs one standard interface for common functions, like ui for instance -- why do we need 50 different UI widget sets? pick one, whether it be gtk or qt or something else, and make it standard. You can be assured everybody with Linux will have that widget set, and so you can confidently write against it without having to add another dependency to your project. Dependencies suck. Look at trying to compile GNOME by hand. You have to track down a metric pantload of different libraries before you can even get the core installed. Yes, package managers make that easier, but there's another problem -- we've got deb, rpm, tgz, and whatever else, and even within those things are different. An rpm for Redhat may or may not install on SuSE or Mandrake, and vice versa.
The point here is that without having some guarantee of what will be available to every end-user (not that they can get it, but that they already have it), few developers but the hardcore will target Linux because they either have to give up potential users or write to the least common denominator (ie, write directly to X for UI work). The former costs potential profits, and the latter is simply way too expensive (not to mention that it's usually only the hardcore that have that kind of knowledge, anyway). Testing for multiple distributions adds major complexity. Text matrices are already huge given the variety of hardware developers need to support. Adding in tests for every distro (multiply the costs of testing by a factor of N, for N distros), and for each distro they have to test scenarios where various optional components are not installed that the software requires. It's a mess, and Linux will have a hard time gaining ISVs if it doesn't do anything about it. Windows isn't better by much (though it's getting there with the death of the Win9x line), but it's still better.
This problem is *hard* to solve. It is a classic chicken and egg. You can't create a distribution until you enter set A, but by the time you've entered set A what's good for you is no longer what's good for average joe.
This is fixable with foresight and some dedication. Oh, yeah, and money helps. Microsoft and Apple do this well, because they can afford usability studies and research. Larger distributions of Linux (Redhat) and other companies (Sun, IBM) should have the capital needed to do such studies, and the clout to enforce the results. Yes, project Foo by developer Baz with no relation to the above may not benefit, or Baz may choose to ignore the findings, but so what? I'm sure there are plenty of other implementations of Foo with developers that will be more receptive to this kind of outside design, and so one (or two, but not more) of those alternatives should be packaged instead. And this should apply through the entire heirarchy, from simple one-man projects to something as large as GNOME. If the GNOME team chooses to ignore usability recommendations (not saying they do, and Sun has done at least one study with resulting recommendations that the team apparently used), then drop them for your distro because I'm sure the KDE guys will be more receptive (not because KDE is better, but because by being receptive to these kinds of suggestions, it means more users for your system -- if your competitor won't bend, then you can take all of the users they would've had by compromising).
together makes one wonder, what developers was (because like it or not, the various Linux distros are trying to target Joe Sixpack-type users these days) Linux trying to target? There are essentially three types of developers in the world, with variations on each:
The casual developer. This guy likes quick&dirty tools, because he's focused on getting the job done. RAD environments like VB or Delphi make it easy for this developer to get his work done with a minimum of fuss. He doesn't spend time thinking about development issues or reading books to learn esoteric (to him) ideas. He pops open his RAD environment with a specific goal, throws together a form that does something (reads data, munges it, spits it out on a form), and is done. I'd say this is the most common developer out there, and thus is why VB and Delphi are so popular. I'd say this group also includes your average sysadmin, if you consider scripting languages to be RAD tools.
The professional developer. This guy is competent, and likes a job well-done, but isn't obsessive-compulsive over having the cleanest or most elegant solution. He's usually writing code under deadline pressure, and it's more important that it works than that it's clean. These guys usually write in Java,.NET languages like C#, or C++, though they often use other languages like SQL or various scripting languages to support their work. The professional developer likes a good IDE, because it helps him get his job done, but he can get by without it holding his hand. He'll often buy books and learn new technologies. These guys are less common than the casual developer.
The hardcore. This includes researchers and the unix-style system programmers. It doesn't matter if it took ten years to ship their product so long as it's elegant and clean. They're obsessive-compulsive about their development environment, and will rage on and on over their choice of editors. These are the guys you'll find in protracted debates about emacs or vi, while everybody else is using neither. They like low-level languages, usually C though some use C++ without being ostracized. They're also fairly uncommon outside of a University setting.
It seems to me that the last developer type is what Linux is targetting. Maybe it's a little short-sighted to target the least-common of developer types?
Regardless, all of that is more or less a red herring today. As I mentioned above, nearly every distro is moving towards one of two things (or both, in the case of Redhat) -- they're targetting servers, or desktop users. The hardcore developers don't really matter, because they know how to get all the tools they need if they're not distributed with the system, like you mentioned. The other types are more or less ignored -- there's no real RAD solution under Linux other than Kylix, and there's no single, coherent object model or set of interfaces (I just re-purposed the word "interface", because while I know you meant "user interface", I think it should also apply to programming interfaces) for writing software (there's GNOME, KDE, GTK, Qt, GNUStep, etc, none of which are guaranteed to be available for any given end-user, so they either have to make a conscious choice to exclude potential customers, or take pains to make sure the neccessary depenedencies are available at install time).
A GOOD cat-back exhaust(catalitic converter all the way back) system DOES add about 5-6 HP. This is a proven fact(I've dyno'd my car before and after..they do). Not all of them sound like scooters either. You can get some GOOD throaty exhaust notes with the right company. Borla for instance.
You're correct, but it depends on the shape of the engine you're dealing with as well. If the car's engine and exhaust system is already pretty well-tuned, you may not even get 5-6 HP, or only at a spike in the rev range. Worse, you may even lose horespower (most of the aftermarket exhaust systems for my car will drop HP -- there are a couple from the high-end tuners like RUF or TechArt that give a marginal increase, but they're not worth the money). You may need to retune your ECU to even see the HP difference. On the other hand, a car like a Civic probably can realistically make 6-12HP off of an exhaust upgrade without even tweaking the ECU, simply because the stock exhaust isn't tuned for performance. You're not going to make 30HP like some... carbohydrate-based staple food racers seem to think. Then again, those are also the guys that think a shit-ton of bodykit and a huge bookshelf spoiler also give them horsepower, so what do you expect? Anyway, for 5-6HP, you'd be better off going on a diet and losing 20 pounds, or getting some lighter wheels to reduce unsprung weight. 5-6HP is less noticeable than losing some extra weight in your car. Sounds better, though:)
As for the stereo..sometimes you think to yourself "damn this song rocks..EVERYONE should hear it.
Ah, but maybe I don't think the song rocks. When I'm driving, I want to hear whatever I'm listening to, whether that be the sound of my engine, the radio, or a CD. I don't want to hear you thumping half a mile away. And dammit, get some dynamat or similar and fix all of those rattles. Bass is less annoying when it's not accompanied by the tell-tale signs of a poor installation job -- buzzing, rattling, etc.
I've heard honda civics that come off the line sounding like Formula 1 cars. All about how much money you have.
Almost understandable, considering that Honda does make F1 cars. However, the real question is why? The amount of money you're going to need to put into that civic to make it run well (more than just engine and exhaust mods, but also suspension, tires, brakes) could be put toward a better car instead. I can understand modifying a Civic for the race track (not drag strip, FWD drag racing seems silly), but I would still have to question it. If your goal is to have a cheap way to start racing, there are better alternatives. For instance, the SCCA spec Miata class is relatively cheap to get into (a couple thousand for a starting car, and maybe another grand or two in modifications, and then you just need to budget for tires and fluids) and is amazingly competitive. On the other hand, if you have a loyalty to Honda then go for it.
If it's a "bling" thing, I think it's a little silly. Really, why does a FWD car need an F1-style spoiler? Adding an "aggressive" body kit is just adding extra weight for your few horses to haul around, and the 5" fart-can exhausts sound like crap and don't do a thing for power (riiiight, you got 30hp from that tip, I'm sure...). And that's not saying anything about adding the really outrageous stereo systems and A/V systems (do you really need a playstation in the center console to distract the driver?).
i never listen to it. the previous owner of the car installed all that crap. i bought the car to drive, and when you have one of the worlds best sounding motors(*1), drowning it out with music is a crime.
The previous owner must've been an idiot. Usually, you'll replace all of that stuff back to stock, and put the system into whatever you get next. If he left it in there, then either he was dumb, or the system is crap. As far as "engine music" goes, I agree but only to an extent. I like my car -- the engine is calm and subdued when I'm just driving around, but as soon as I open up, it has a really beautiful sound, especially in the high rev range. Of course, there's overkill on the stereo system, too. My car is completely stock (doesn't even have rear speakers), and that's good enough for me.
(emphasis added by me)
shouldn't car buying revolve around performance, safety, and price ?
Funny one. If that were the case, nobody would be buying SUVs. The frame-on-body truck-based SUVs are notoriously unsafe for both the driver and whoever they hit, the prices on most SUVs are outrageous, and the performance is terrible when you consider the power to weight ratio. More, performance can be judged by other things than horespower and torque. Can your car carve the twisties like it's on rails? I can guarantee you that very few SUVs can (the new Porsche Pepper Truck... err, Cayenne... can, but I've been told it feels more like a sports sedan than a sports car -- not bad, considering its an SUV, but not what I would expect from a Porsche either).
A very important detail is those curves aren't fixed. The supply curve could "slide" left or ride - same applies to the demand curve. This, obviously, related to forces outside of simple demand.
Very true, but that doesn't change the fundamentals of how S/D curves flow. The curves can shift, they can be flatter or steeper, they can even be true curves rather than lines, but the basics are still the same. Demand drives costs in a downward direction, while supply increases as price goes up. Where the lines meet, you have your optimum price.
You're right that there are forces outside of "simple" demand and supply, but I'm talking in relation to macro economics (market-level) rather than micro economics (firm-level).
Re:This is why HDTV will never happen in 2006
on
LCD Price Fixing?
·
· Score: 1
The prices of... HDTV's are fscking ridiculous! When they get to $300 let me know......
How about this? A 27" HDTV CRT for $650. Sure, it's higher than your $300 limit, but it's pretty damned good for a decent-sized CRT that can handle 1080i (sadly, no 720p). For most people, though, going to HDTV also means going to a larger/wider screen. Larger and wider means more expensive.
However, the FCC has already thought about this. That's why you'll be able to buy down-convertors so you can still watch modern HDTV broadcasts on your aging non-HDTV monitor. Of course, a better monitor has more advantages than just watching HDTV. You get progressive scan (assuming you have a source that outputs in progressive, or a decent line-doubler) so your DVDs look better, and modern gaming consoles take advantage of that as well (99% of all XBox games support 480p with a few even at 720p or 1080i, most Gamecube games do 480p as well, some newer PS2 games do 480p, and even nearly every Dreamcast game does 480p with the proper connector). Plus, it makes a computer hooked to your TV more readable (assuming you have vga, RGBHV, or DVI inputs, or buy a transcoder to go from VGA/RGBHV to YPrPb, and take the time to tweak your modes to get a useable display with minimal overscan).
I think 17" qualifies as UXGA (I think 1280x1024), which of course, can be had for $500. I am pretty sure one can get a laptop with 1400something x 1000 screen for $1000. Not exactly an apples comparison but the laptop has a better resolution screen than what you can find as a stand-alone monitor for $1000.
Nope. UXGA is a resolution measure (1600x1200), not size, and generally is found on 15"+ laptop LCDs (and usually you pay a premium for it, so I'd like to know where the author found this $1000 UXGA laptop), and even on a few 14.x" laptop LCDs. The 15", 17", and even most 19" desktop LCD displays I've seen in stores (sub-$1000 for most of them, but close to or slightly over $1000 for some of the 19"s) are all 1280x1024, which make them not UXGA. From Pricewatch, 19" UXGA LCD monitors start at $845, and quickly goes up from there if you want a quality name-brand. There are no 17" UXGA LCD monitors listed on Pricewatch.
Prices rise as demand increases relative to supply and fall as demand decreases.
That's not how I remember my economics. You have your basic supply/demand curve, with price on the Y axis, and units on the X. As price goes up, more units can be supplied, so the supply curve has an increasing slope. Conversely, there is more demand as price drops (units become more affordable). In other words, the demand curve has a decreasing slope. In ascii art (please let this look decent...):
p |\ d/ r | \/ i | X c | / \ e |/s \
+-------------
units
d = demand curve s = supply curve
(the curves aren't very curvy in this example, but they could be depending on the supply and demand dynamics)
Price is always determined by the demand curve, with the supply curve denoting how many units can be built at a given price. If the price is high, the demand is low, and although many units can be supplied at that price, that's only theoretical -- nobody's buying, so there's no money to manufacture those units. There are always the economincally-enabled few that can afford anything at any price, and the bleeding-edge early adopters that will pay a premium for being the first on the block, but most people won't buy until the price has dropped. When the two cross, you're at the optimum price (for a non-monopolistic competitive market). After that point, more units can't be supplied because the sales won't cover costs, and before that point fewer people will buy because the price is too high. This is where you get into loss-leader (selling to the right of the optimum point, below cost, to generate more demand) and monopoly (selling to the left of the optimum point, because nobody can compete with you to keep your prices down -- there's a point where the price is high enough to allow others into the market, but so long as the monopoly keeps the price below that point, it's got the market to itself).
Now, what the original poster was suggesting (I believe -- and if not, it's what I'm suggesting) is that laptop LCDs are being sold at a price on the demand curve to the right of the optimum point (lower price), but the manufacturers can afford to do so by selling non-laptop LCDs (desktops, TVs) at a price on the demand curve to the left of the optimum point. If things are ideal, the merged graph should come out with the combined demand and supply crossing properly at the averaged price. I doubt that's the case. It's likely that the price is higher than that, but it shouldn't be by much -- if it were, then competitors would lower their prices to gain more marketshare.
And just to CMA, it's been 3-ish years since I've had an economics course, so my analysis may be off, but my graph (ugly as it is) should be correct for a baseline S/D graph.
While media computers are interesting, I don't see them becoming a mainstream phenomenon anytime soon. Joe Sixpack does not want to deal with the hassle of sticking a computer next to his TV.
That's the point of a real media computer. You're right that Joe Sixpack doesn't want to deal with the hassles of sticking a computer next to his TV, so companies are working on making it foolproof. Witness the Tivo. That's basically a computer, though specialized somewhat, and Joe Sixpack has no problems with it because it's idiot-proof. Plug it in, turn it on, go through some standard setup (no worse than setting the clock on your VCR), and you're done. Microsoft's Media Center PCs still need some work, but they're pretty close too -- plug it in, turn it on, and you're more or less good to go. You can still get to a desktop, though, which isn't a good idea for Joe Sixpack. The Media Center interface is good, though, so as long as the users stay within that, the experience should be painless.
From reading the reposts of the article (thanks, Slashdot, for killing the article), it sounds like Lindows' media computer isn't anywhere near that level. In fact, I've seen hobbyist HTPCs that were more integrated and seamless than the Lindows offering seems to be (Lindows doesn't seem to have the media computer anywhere on their site, as far as I could find).
M4 gets a bad reputation because of Sendmail. However, M4 is pretty cool, and quite useful. For example, I've used it in the past as a way to add includes and macros to SQL code (SQL code being built in a build environment, generally object defintions and stored procedures, run through the command line tool for whatever database you're using). That let me abstract out common pieces of code, minimizing copy&paste errors.
In general, M4 is just a macro processor, where there are some pre-defined macros, and you can define your own macros as well as changing various behaviors of M4. For example, to use my SQL example above, it was trivial to change M4's quoting characters to {} from `' (Because the `' quoting conflicted with SQL's '' quoting), and it was necessary to prefix M4 builtins with m4_ because SQL has some similarly-named functions (len(), for example). This was trivially done and stored in a "freeze" file for easy retrieval later. Write your M4 code to the changed definitions, and run M4 by specifying the freeze file. In essence, that's all Sendmail is doing -- Sendmail has defined some M4 macros, and you just use those macros to create your config. In Sendmail's case, the macros are poorly documented, and that makes configuration a real bear. But that's not M4's fault. It's Sendmail's.
Re:Refactoring does not depend on Eclipse: Emacs!
on
Eclipse 2.1 Released
·
· Score: 1
I wish I knew where this idiotic notion that you should be able to do your job without learning how to use the necessary tools comes from, but it seems that it's becoming more common over time -- a depressing thought, to say the least. It's this thinking that's behind the belief people have that they should be able to use the computer, including all the programs on it, without having ever learned anything about it first.
I think you missed the point. Basically, what the poster was trying to say is that learning emacs is a full-time job. Of course you have to learn the tools you want/need to use, and if there's a new tool or set of tools you need to learn to do a job, then that should be factored into your estimate and charged appropriately. The problem is that emacs takes damned long to learn all of the ins and outs. Sure, you can fire it up and start using it by only knowing a few commands, but it's highly unlikely you'll be as productive as you would with a less-featureful but more-intuitive tool.
If automobiles hadn't been around for so long, people would probably think that they should be able to get into a car and drive without learning anything about driving, too. It's probably only because the people who made the automobile into an integral part of our society weren't as lazy and stupid as people today that this notion never made it into the automobile culture...
It hasn't? Driver education in the US is a joke, and most people do believe that they should be able to get into a car and drive without learning anything at all about driving. To some extent, that is true -- the interface on most automobiles is simple enough that you can simply get in and drive, with all of the major controls in similar places, if not exactly the same place. You won't necessarily be very good at it, but you can still do it.
or barron of beef with 'aux jus'.. that's barron of beef with 'with the juices'... damn idiots
That's almost excusable, since it's mixing languages (like the infamous movie watched on MST3K, "Manos, the Hands of Fate", which translates to "Hands, the Hands of Fate"). However, if I have to listen to another person tell me they're going to the "ATM machine", I just might hit them.
Re:Refactoring does not depend on Eclipse: Emacs!
on
Eclipse 2.1 Released
·
· Score: 1
That's hilarious! It's ingenious the way you called emacs a "better IDE". Pure comedy gold.
In some ways a basic text editor is easier to work with, of course the nice color coding makes reading your code easier but really your code, when properly formatted(indenting and so forth), should be easy to read in a text editor.
Color coding is nice so you can see at a glance what is a variable, what is a function call, what's a constant, etc. Sure, you can do that with naming conventions (variables get lowerCaseCamelCasing, functions get UpperCaseCamelCasing, constants are ALLCAPS, etc), but that still requires more parsing than just seeing that variables are blue, functions are red, and constants are green. As well, it also helps you determine whether or not you've got a large block of commented-out code (yeah, sure, you don't leave dead code in your source files -- now try supporting someone else's source code). It's easier to see that a block is commented out when comments are blue on light-gray, rather than searching for that closing */ (it also will show you the error of nesting/**/ comments before you get to compile-time and see the build error). Finally, color-coding isn't all there is to an IDE's editor. Good IDEs will cross-reference your code, so you don't have to go digging for that Foo() function -- just [shift|control|] [double-|right-]click on the function, and there it is. Sure, you can do this with ctags and emacs or vi, but not with notepad, and not without an extra step -- building the tags.
Next to my text editor I have my console in which I type make and my app gets compiled as easy as 1,2,3.
Visual Studio can make a project out of a make (well, nmake) file, and you can turn a project back into a makefile. As well, we use a commandline-based build process at work (ultimately based on nmake, but with a lot of customizations on top in the form of batch scripts, perl scripts, WSH scripts, and executeables), and it's still more convenient to write code in the IDE but click over to a cmd.exe prompt to run a build.
One of the things that attracts most people to IDEs is that a lot of them come with code wizards and so forth that help with the basic layout of applications. I have never found these to be of much use because I end up scrapping much of the code because it usually isn't as concise as I like it.
To each his own, and I'm sure you've got your own personal library of boiler-plate code you pull from all the time. Most good programmers do. However, recent IDEs (well, VS.NET:) do create fairly good boiler-plate code, and it takes a lot of the tediousness out of development, letting you get to the core logic without having to niggle around with your message pump, or setting up a standard window, or whatever.
I've not used dev-cpp, but it's still fairly young and surely has a way to go. VS.NET is much better than VS6 (which itself was better than VS5). It's all good and well to be hardcore and prefer your favorite text editor (I still whip out vim for most scripting jobs, whether it be nt command/batch script, vbscript or jscript, perl, or php), but a good IDE is an invaluable tool for any programmer, novice to expert.
Slashdot Mirror
Not a friend of mine, just a good link I'd found before that actually detailed what's wrong Bose. I agree that right-click disabling is the most annoying thing ever (and useless -- View->Source in IE gets you the frameset source, which tells you the frame page, where you can again View->Source and get the source). I'll paste the contents of the page as an AC below this thread, so you can read them.
The products don't support Bose with good reason. These remotes are meant for relatively high-end or better mid-level systems, which Bose isn't.
Same here. I had several problems with my old Deskjet 500. The least trivial was a bad power cord. It developed a short early in its lifetime, and ever after would kill power at the slightest bump and required contortions to get power in the first place. Easily replaceable, but not when you're a college student on a budget using a hand-me-down printer. The second problems was more painful, and more expensive to fix (to the point where it was cheaper to buy a new printer). The paper feed mechanism wore down (it was a friction feed, like most printers are) and would misfeed paper at the most inopportune times. Ten pages into a twenty page paper, the printer would decide to feed five pieces of paper into the tray rather than one. Worse, sometimes it would skew the paper, or even stop feeding at all (your printed page ended up being jumbled into a single line -- try handing that in!).
I "fixed" this by switching to LyX (because I didn't want to learn TeX/LaTeX syntax, and because Word kept screwing up footnotes by misnumbering them or putting them on the wrong page) for use on our engineering workstations (Suns, IBMs, and HPs), and printing with my 500 page laser printer quota (free printing! You couldn't print more than 500 pages per semester, and your balance didn't roll over by semester, but it was more than sufficient and better than going to the campus-wide non-engineering labs and paying for printer use).
I don't give a crap about the "Wurld Domeenashun" crowd. It's the Redhats and IBMs that are driving Linux as a platform (and not as a kernel) towards wider acceptance on the server and on the workstation. Your "fix it or go away" mindset is what's working against these companies trying to get wider mindshare for Linux. For every IBM out there, there are literally thousands of you. The odds are against them, and that's a problem. For me, I've found another platform. I don't use Linux on the desktop, and won't be any time soon. As well, I don't do Linux development (unless you count the small bit of php I do for my personal site) because of the issues I raised above. I won't be doing any Linux programming, either, until a majority of the problems I brought up are satisfactorily solved (effectively, that means it's highly unlikely I'll ever do any professional Linux programming, or even widely-distributed personal projects). I'm not in a position where I can effect those changes, so your "put up or shut up" argument carries no weight.
You missed the point. I don't care that you can use them all concurrently. I want to be guaranteed that the widget set I target will be on the users system without me having to distribute it, and without them having to do anything extra. Thus, pick one or two, and have every distro include them.
See the discussion about short-comings and incompatibilities among package managers. GNOME was an example, but it can apply to applications as well -- if my application uses libraries you don't have, then you need to get those libraries before you can use my application. I could distribute those libraries (bad idea), or I could reinvent the wheel once again to remove the dependency (another bad idea). The proper solution is to standardize on some set of libraries for common functions that would guarantee that my application has what it needs (note: esoteric libraries are the exception -- I'm fine taking a dependency on something like a high-level mathematics library, because I don't expect every system to have that. I am not willing to take a dependency on some ui widget set because that should be standard across distros. I don't want to have to worry about whether or not my users have GTK, QT, or if they've only installed TK and nothing more).
This one is fairly easy if you subscribe to free market economics (if you're into socialism or communism, the answer is still easy, but it's the opposite ...). First, let's get the "legal action" issue sorted out. Microsoft rarely uses legal action (no, really, check it out. Microsoft is usually on the receiving end, not the giving end). You misrepresent the Lindows suit. That was over a name. All Lindows had to do was change their name, and they could continue to do business (and IMHO, the lawsuit was justified because the name was intentionally chosen to be similar to a Microsoft product which it was aiming at replacing -- if Microsoft change the name of SQL Server to Boracle, or changed Windows to Wolaris, everybody here would be up in arms, but because Lindows is a Linux company and an underdog, they don't get any flak for the name they chose ...).
So, assuming that the largest of the large companies tend not to use legal actions, let's throw that out and look at economic factors. Sure, Microsoft is a monopoly in the operating system arena (being a monopoly is not illegal, but abusing the position is). However, except in the very extreme case of a corporation abusing its monopoly power (Standard Oil, but not IBM, and not Microsoft to some extent), the government should step out and let the market control itself. Yes, there are issues with a free market economy having cyclic highs and lows, but the government can lessen the impact of those almost totally through the manipulation of interest rates and nothing more. If a smaller company cannot compete with a larger one, then the market decided.
9 out of every 10 businesses (warning! I made up the numbers, but the ratio is really that high) go under. The upside is that every day people create new businesses. In most markets, when one business goes under there are several others ready to step in and take its place (alternatively, that business was in a market that didn't exist, like a lot of dot-com companies -- when the bubble burst, they went away and nobody replaced them because the markets they were in were largely fictional).
Interesting. Could you expand please? What ethical questions exist around .NET that wouldn't exist around any other development architecture? Are you referring to Microsoft's Shared Source program and their Shared Source implementation of the ECMA standard in Rotor? Or how about Microsoft submitting only portions of their .NET platform for ECMA standardization, and whether or not those portions are useful as a complete system (without a database layer, ui layer, etc)? How does that compare with Sun, who will not submit even a portion of the Java platform to a standardization body? You were probably just being facetious, but this could be an interesting ethical area to explore.
Perhaps you mean to say that current IDEs suck? What's stopping an IDE from integrating autotools support? I'd use it. I don't know how to use autoconf/automake (more from lack of caring than anything), but I think if an IDE made it easy for me, I would. As well, why does an IDE need to support autotools? There's no reason why you need to compile within an IDE. I spend probably 95% of my programming time writing code in an IDE but compiling it from the commandline. I don't use the IDE to compile, but I'm not going to switch to notepad because I like all the extra features I get from the various IDEs I like.
And unless you're writing assembly code, you're never (well, 99.5% of the time) going to see any of those differences. The compiler should take care of those small differences.
And now you've got a debian-only distributable. People cry foul when someone like Oracle (for example) releases their product only for Redhat, but that's what developers are forced to do. Distributions are just too different for a developer to support more than one or two of them. I know there's the FSH, but filesystem standards aren't enough. Linux needs one standard interface for common functions, like ui for instance -- why do we need 50 different UI widget sets? pick one, whether it be gtk or qt or something else, and make it standard. You can be assured everybody with Linux will have that widget set, and so you can confidently write against it without having to add another dependency to your project. Dependencies suck. Look at trying to compile GNOME by hand. You have to track down a metric pantload of different libraries before you can even get the core installed. Yes, package managers make that easier, but there's another problem -- we've got deb, rpm, tgz, and whatever else, and even within those things are different. An rpm for Redhat may or may not install on SuSE or Mandrake, and vice versa.
The point here is that without having some guarantee of what will be available to every end-user (not that they can get it, but that they already have it), few developers but the hardcore will target Linux because they either have to give up potential users or write to the least common denominator (ie, write directly to X for UI work). The former costs potential profits, and the latter is simply way too expensive (not to mention that it's usually only the hardcore that have that kind of knowledge, anyway). Testing for multiple distributions adds major complexity. Text matrices are already huge given the variety of hardware developers need to support. Adding in tests for every distro (multiply the costs of testing by a factor of N, for N distros), and for each distro they have to test scenarios where various optional components are not installed that the software requires. It's a mess, and Linux will have a hard time gaining ISVs if it doesn't do anything about it. Windows isn't better by much (though it's getting there with the death of the Win9x line), but it's still better.
This is fixable with foresight and some dedication. Oh, yeah, and money helps. Microsoft and Apple do this well, because they can afford usability studies and research. Larger distributions of Linux (Redhat) and other companies (Sun, IBM) should have the capital needed to do such studies, and the clout to enforce the results. Yes, project Foo by developer Baz with no relation to the above may not benefit, or Baz may choose to ignore the findings, but so what? I'm sure there are plenty of other implementations of Foo with developers that will be more receptive to this kind of outside design, and so one (or two, but not more) of those alternatives should be packaged instead. And this should apply through the entire heirarchy, from simple one-man projects to something as large as GNOME. If the GNOME team chooses to ignore usability recommendations (not saying they do, and Sun has done at least one study with resulting recommendations that the team apparently used), then drop them for your distro because I'm sure the KDE guys will be more receptive (not because KDE is better, but because by being receptive to these kinds of suggestions, it means more users for your system -- if your competitor won't bend, then you can take all of the users they would've had by compromising).
Putting
and
together makes one wonder, what developers was (because like it or not, the various Linux distros are trying to target Joe Sixpack-type users these days) Linux trying to target? There are essentially three types of developers in the world, with variations on each:
It seems to me that the last developer type is what Linux is targetting. Maybe it's a little short-sighted to target the least-common of developer types?
Regardless, all of that is more or less a red herring today. As I mentioned above, nearly every distro is moving towards one of two things (or both, in the case of Redhat) -- they're targetting servers, or desktop users. The hardcore developers don't really matter, because they know how to get all the tools they need if they're not distributed with the system, like you mentioned. The other types are more or less ignored -- there's no real RAD solution under Linux other than Kylix, and there's no single, coherent object model or set of interfaces (I just re-purposed the word "interface", because while I know you meant "user interface", I think it should also apply to programming interfaces) for writing software (there's GNOME, KDE, GTK, Qt, GNUStep, etc, none of which are guaranteed to be available for any given end-user, so they either have to make a conscious choice to exclude potential customers, or take pains to make sure the neccessary depenedencies are available at install time).
You're correct, but it depends on the shape of the engine you're dealing with as well. If the car's engine and exhaust system is already pretty well-tuned, you may not even get 5-6 HP, or only at a spike in the rev range. Worse, you may even lose horespower (most of the aftermarket exhaust systems for my car will drop HP -- there are a couple from the high-end tuners like RUF or TechArt that give a marginal increase, but they're not worth the money). You may need to retune your ECU to even see the HP difference. On the other hand, a car like a Civic probably can realistically make 6-12HP off of an exhaust upgrade without even tweaking the ECU, simply because the stock exhaust isn't tuned for performance. You're not going to make 30HP like some ... carbohydrate-based staple food racers seem to think. Then again, those are also the guys that think a shit-ton of bodykit and a huge bookshelf spoiler also give them horsepower, so what do you expect? Anyway, for 5-6HP, you'd be better off going on a diet and losing 20 pounds, or getting some lighter wheels to reduce unsprung weight. 5-6HP is less noticeable than losing some extra weight in your car. Sounds better, though :)
Ah, but maybe I don't think the song rocks. When I'm driving, I want to hear whatever I'm listening to, whether that be the sound of my engine, the radio, or a CD. I don't want to hear you thumping half a mile away. And dammit, get some dynamat or similar and fix all of those rattles. Bass is less annoying when it's not accompanied by the tell-tale signs of a poor installation job -- buzzing, rattling, etc.
Almost understandable, considering that Honda does make F1 cars. However, the real question is why? The amount of money you're going to need to put into that civic to make it run well (more than just engine and exhaust mods, but also suspension, tires, brakes) could be put toward a better car instead. I can understand modifying a Civic for the race track (not drag strip, FWD drag racing seems silly), but I would still have to question it. If your goal is to have a cheap way to start racing, there are better alternatives. For instance, the SCCA spec Miata class is relatively cheap to get into (a couple thousand for a starting car, and maybe another grand or two in modifications, and then you just need to budget for tires and fluids) and is amazingly competitive. On the other hand, if you have a loyalty to Honda then go for it.
If it's a "bling" thing, I think it's a little silly. Really, why does a FWD car need an F1-style spoiler? Adding an "aggressive" body kit is just adding extra weight for your few horses to haul around, and the 5" fart-can exhausts sound like crap and don't do a thing for power (riiiight, you got 30hp from that tip, I'm sure ...). And that's not saying anything about adding the really outrageous stereo systems and A/V systems (do you really need a playstation in the center console to distract the driver?).
The previous owner must've been an idiot. Usually, you'll replace all of that stuff back to stock, and put the system into whatever you get next. If he left it in there, then either he was dumb, or the system is crap. As far as "engine music" goes, I agree but only to an extent. I like my car -- the engine is calm and subdued when I'm just driving around, but as soon as I open up, it has a really beautiful sound, especially in the high rev range. Of course, there's overkill on the stereo system, too. My car is completely stock (doesn't even have rear speakers), and that's good enough for me.
(emphasis added by me)
Funny one. If that were the case, nobody would be buying SUVs. The frame-on-body truck-based SUVs are notoriously unsafe for both the driver and whoever they hit, the prices on most SUVs are outrageous, and the performance is terrible when you consider the power to weight ratio. More, performance can be judged by other things than horespower and torque. Can your car carve the twisties like it's on rails? I can guarantee you that very few SUVs can (the new Porsche Pepper Truck ... err, Cayenne ... can, but I've been told it feels more like a sports sedan than a sports car -- not bad, considering its an SUV, but not what I would expect from a Porsche either).
More accurately, it sounds like an overgrown bumblebee with a cold.
Bob loves you.
Very true, but that doesn't change the fundamentals of how S/D curves flow. The curves can shift, they can be flatter or steeper, they can even be true curves rather than lines, but the basics are still the same. Demand drives costs in a downward direction, while supply increases as price goes up. Where the lines meet, you have your optimum price.
You're right that there are forces outside of "simple" demand and supply, but I'm talking in relation to macro economics (market-level) rather than micro economics (firm-level).
How about this? A 27" HDTV CRT for $650. Sure, it's higher than your $300 limit, but it's pretty damned good for a decent-sized CRT that can handle 1080i (sadly, no 720p). For most people, though, going to HDTV also means going to a larger/wider screen. Larger and wider means more expensive.
However, the FCC has already thought about this. That's why you'll be able to buy down-convertors so you can still watch modern HDTV broadcasts on your aging non-HDTV monitor. Of course, a better monitor has more advantages than just watching HDTV. You get progressive scan (assuming you have a source that outputs in progressive, or a decent line-doubler) so your DVDs look better, and modern gaming consoles take advantage of that as well (99% of all XBox games support 480p with a few even at 720p or 1080i, most Gamecube games do 480p as well, some newer PS2 games do 480p, and even nearly every Dreamcast game does 480p with the proper connector). Plus, it makes a computer hooked to your TV more readable (assuming you have vga, RGBHV, or DVI inputs, or buy a transcoder to go from VGA/RGBHV to YPrPb, and take the time to tweak your modes to get a useable display with minimal overscan).
Nope. UXGA is a resolution measure (1600x1200), not size, and generally is found on 15"+ laptop LCDs (and usually you pay a premium for it, so I'd like to know where the author found this $1000 UXGA laptop), and even on a few 14.x" laptop LCDs. The 15", 17", and even most 19" desktop LCD displays I've seen in stores (sub-$1000 for most of them, but close to or slightly over $1000 for some of the 19"s) are all 1280x1024, which make them not UXGA. From Pricewatch, 19" UXGA LCD monitors start at $845, and quickly goes up from there if you want a quality name-brand. There are no 17" UXGA LCD monitors listed on Pricewatch.
That's not how I remember my economics. You have your basic supply/demand curve, with price on the Y axis, and units on the X. As price goes up, more units can be supplied, so the supply curve has an increasing slope. Conversely, there is more demand as price drops (units become more affordable). In other words, the demand curve has a decreasing slope. In ascii art (please let this look decent ...):
Price is always determined by the demand curve, with the supply curve denoting how many units can be built at a given price. If the price is high, the demand is low, and although many units can be supplied at that price, that's only theoretical -- nobody's buying, so there's no money to manufacture those units. There are always the economincally-enabled few that can afford anything at any price, and the bleeding-edge early adopters that will pay a premium for being the first on the block, but most people won't buy until the price has dropped. When the two cross, you're at the optimum price (for a non-monopolistic competitive market). After that point, more units can't be supplied because the sales won't cover costs, and before that point fewer people will buy because the price is too high. This is where you get into loss-leader (selling to the right of the optimum point, below cost, to generate more demand) and monopoly (selling to the left of the optimum point, because nobody can compete with you to keep your prices down -- there's a point where the price is high enough to allow others into the market, but so long as the monopoly keeps the price below that point, it's got the market to itself).Now, what the original poster was suggesting (I believe -- and if not, it's what I'm suggesting) is that laptop LCDs are being sold at a price on the demand curve to the right of the optimum point (lower price), but the manufacturers can afford to do so by selling non-laptop LCDs (desktops, TVs) at a price on the demand curve to the left of the optimum point. If things are ideal, the merged graph should come out with the combined demand and supply crossing properly at the averaged price. I doubt that's the case. It's likely that the price is higher than that, but it shouldn't be by much -- if it were, then competitors would lower their prices to gain more marketshare.
And just to CMA, it's been 3-ish years since I've had an economics course, so my analysis may be off, but my graph (ugly as it is) should be correct for a baseline S/D graph.
That's the point of a real media computer. You're right that Joe Sixpack doesn't want to deal with the hassles of sticking a computer next to his TV, so companies are working on making it foolproof. Witness the Tivo. That's basically a computer, though specialized somewhat, and Joe Sixpack has no problems with it because it's idiot-proof. Plug it in, turn it on, go through some standard setup (no worse than setting the clock on your VCR), and you're done. Microsoft's Media Center PCs still need some work, but they're pretty close too -- plug it in, turn it on, and you're more or less good to go. You can still get to a desktop, though, which isn't a good idea for Joe Sixpack. The Media Center interface is good, though, so as long as the users stay within that, the experience should be painless.
From reading the reposts of the article (thanks, Slashdot, for killing the article), it sounds like Lindows' media computer isn't anywhere near that level. In fact, I've seen hobbyist HTPCs that were more integrated and seamless than the Lindows offering seems to be (Lindows doesn't seem to have the media computer anywhere on their site, as far as I could find).
M4 gets a bad reputation because of Sendmail. However, M4 is pretty cool, and quite useful. For example, I've used it in the past as a way to add includes and macros to SQL code (SQL code being built in a build environment, generally object defintions and stored procedures, run through the command line tool for whatever database you're using). That let me abstract out common pieces of code, minimizing copy&paste errors.
In general, M4 is just a macro processor, where there are some pre-defined macros, and you can define your own macros as well as changing various behaviors of M4. For example, to use my SQL example above, it was trivial to change M4's quoting characters to {} from `' (Because the `' quoting conflicted with SQL's '' quoting), and it was necessary to prefix M4 builtins with m4_ because SQL has some similarly-named functions (len(), for example). This was trivially done and stored in a "freeze" file for easy retrieval later. Write your M4 code to the changed definitions, and run M4 by specifying the freeze file. In essence, that's all Sendmail is doing -- Sendmail has defined some M4 macros, and you just use those macros to create your config. In Sendmail's case, the macros are poorly documented, and that makes configuration a real bear. But that's not M4's fault. It's Sendmail's.
I think you missed the point. Basically, what the poster was trying to say is that learning emacs is a full-time job. Of course you have to learn the tools you want/need to use, and if there's a new tool or set of tools you need to learn to do a job, then that should be factored into your estimate and charged appropriately. The problem is that emacs takes damned long to learn all of the ins and outs. Sure, you can fire it up and start using it by only knowing a few commands, but it's highly unlikely you'll be as productive as you would with a less-featureful but more-intuitive tool.
It hasn't? Driver education in the US is a joke, and most people do believe that they should be able to get into a car and drive without learning anything at all about driving. To some extent, that is true -- the interface on most automobiles is simple enough that you can simply get in and drive, with all of the major controls in similar places, if not exactly the same place. You won't necessarily be very good at it, but you can still do it.
That's almost excusable, since it's mixing languages (like the infamous movie watched on MST3K, "Manos, the Hands of Fate", which translates to "Hands, the Hands of Fate"). However, if I have to listen to another person tell me they're going to the "ATM machine", I just might hit them.
That's hilarious! It's ingenious the way you called emacs a "better IDE". Pure comedy gold.
Color coding is nice so you can see at a glance what is a variable, what is a function call, what's a constant, etc. Sure, you can do that with naming conventions (variables get lowerCaseCamelCasing, functions get UpperCaseCamelCasing, constants are ALLCAPS, etc), but that still requires more parsing than just seeing that variables are blue, functions are red, and constants are green. As well, it also helps you determine whether or not you've got a large block of commented-out code (yeah, sure, you don't leave dead code in your source files -- now try supporting someone else's source code). It's easier to see that a block is commented out when comments are blue on light-gray, rather than searching for that closing */ (it also will show you the error of nesting /**/ comments before you get to compile-time and see the build error). Finally, color-coding isn't all there is to an IDE's editor. Good IDEs will cross-reference your code, so you don't have to go digging for that Foo() function -- just [shift|control|] [double-|right-]click on the function, and there it is. Sure, you can do this with ctags and emacs or vi, but not with notepad, and not without an extra step -- building the tags.
Visual Studio can make a project out of a make (well, nmake) file, and you can turn a project back into a makefile. As well, we use a commandline-based build process at work (ultimately based on nmake, but with a lot of customizations on top in the form of batch scripts, perl scripts, WSH scripts, and executeables), and it's still more convenient to write code in the IDE but click over to a cmd.exe prompt to run a build.
To each his own, and I'm sure you've got your own personal library of boiler-plate code you pull from all the time. Most good programmers do. However, recent IDEs (well, VS.NET :) do create fairly good boiler-plate code, and it takes a lot of the tediousness out of development, letting you get to the core logic without having to niggle around with your message pump, or setting up a standard window, or whatever.
I've not used dev-cpp, but it's still fairly young and surely has a way to go. VS.NET is much better than VS6 (which itself was better than VS5). It's all good and well to be hardcore and prefer your favorite text editor (I still whip out vim for most scripting jobs, whether it be nt command/batch script, vbscript or jscript, perl, or php), but a good IDE is an invaluable tool for any programmer, novice to expert.