Reading their technology explanation, the idea certainly seems reasonable enough! The trick being of course in the manufacturing of the two very close but seperated layers.
If I understood their physics-for-dummies explanation correctly, the principle relies on two metals separated by a very thin gap; a potential difference across the plates encourages tunneling of electrons across the gap, carrying heat with them.
IANAP, but I'm sure someone here is: doesn't vibration at the atomic scale in some crystalline medium also act like a particle? Can these guys also tunnel across gaps, or is their weird quantum nature restricted to the single medium they're expressed in? If they could tunnel, I would have thought that as the heat differential across the plates increased, their tunneling would also increase, acting as a break on the process and bringing about an equilibrium situation (temperature differential vs. potential differential.) Or is the mechanism for equilibrium simply black-body radiation across the gap, or similar?
What sort of temperature differentials are possible through a device like this? Is it only limited by mechanical constraints?
That's one hell of a rejoinder to a throw-away comment.
More specifically: there are much larger margins on server-targeted hardware, such as tape drives, than there is in the desktop arena. While 5-10% margins are common at the retail level for consumer hardware, tape systems seem to start at 20% and go up from there.
Even acknowledging the fact that these are mechanical devices and so will naturally not benefit so greatly from the price drops in other computer hardware, tape backup prices have barely fallen at all in the last 4 years. As higher capacities and speeds are introduced, they just come out at higher and higher pricepoints.
There doesn't need to be an organised cabal - when you have a market which is willing to pay these prices, and where there are often established long-term relationships between the buyers and vendors, it's unsurprising that there hasn't been the same downward pressure on prices. Unlike in consumer hardware, where there is typically little brand loyalty and price-competition is fierce.
Final concrete example: getting SCSI hardware in an external enclosure typically costs about 12% more than when it is bare. At the cheap end, it's about what you'd expect to pay for a decent enclosure. At the expensive end, it's about 3 or 4 times the retail cost of a similar enclosure. Where's the competition driving prices down here?
Oh, and don't be so quick to call people retards. It's rude on a number of levels.
Somehow I think that my explanation for the price disparity between IDE and SCSI is a lot more plausible than one which requires every single hard-drive manufacturer on the planet to be organized in a cabal, whose sole purpose is to drive up the price of server-class hardware.
Have you looked at the tape-drive/media market recently? My money's on the cabal.
The holes are merely lack of electrons, and act like a physical entity, but is really the lack of an entity.
That's a bit harsh I think:) Holes act like particles - like electrons do - and so in the solid-state domain, they're just as much a physical entity. Outside that domain of course, they don't make much sense. Electrons get around more and get all the girls.
I think that is what is usually called a straw-man argument.
Few if any people are promoting the idea of electric-only cars powered by traditional batteries, and refilled by plugging it into the wall socket. For the very reasons you describe, it would be expensive and ineffective.
As described in the article, and often on slashdot, the idea is to have a fuel cell in the car which uses hydrogen very efficiently. The problem then becomes a matter of storing and generating the hydrogen. Storing it (and there are a number of options) is expensive but possible. The fact that there are working experimental hydrogen-based cars demonstrates this. It is a one-off cost though, so shouldn't be taken too seriously.
Generating the hydrogen can be done at the site of another form of power generation. Even if this is done with coal and oil plants (which of course is a very poor way to create power to begin with when compared with (say) natural gas) one eliminates the losses due to power transmission etc. Further, the pollution that eminates from the burning of fossil fuels is much more easily contained at a single site (like a power station) than it is when it's generated by 234723849 cars.
There are much more efficient ways of generating hydrogen though, from natural gas or methane directly, which completely bypass the very dirty and relatively inefficient coal and oil power production systems.
The only reason why hybrid cars are the best solution right now, is that there is a lack of a hydrogen supply infrastructure. Fix that, and hydrogen as energy storage comes into its own. Again, as described in the article, a promising avenue to this is through converting local bus services to hydrogen-based, which even in the absence of an established hydrogen infrastructure, can then be cheaper to run. This in turn creates a market for distribution,
I'm going to try and summarize your argument in order to attack it, but I may be misrepresenting it; if so, please accept my apologies in advance!
The key point seems to be if there is a large amount of no-charge freely-copyable software available which is adequate for most tasks, then it will be impossible for companies to economically produce very good commercial software. The reason for this being that too many people will be happy to make do with the free alternatives, and so the cost of production of the really good software could never be recouped.
This may indeed be a force towards the production of less commercial software. On the other hand, the availability of a wide code-base that is freely available for use in free software means that the cost of development of new free software is also made that much lower. If the market ever reaches such a state (and I admit to being highly sceptical that it will while the current IP regime remains in place), then in those areas where free and commercial software are competing, the same force that makes the commercial software less viable makes it more likely that the free software can be cheaply and easily shaped to fit the task.
There are some areas where such competition seems less likely, such as those where there is a large amount of non-code labour required. The primary example here is that of modern computer games. Here novelty and pretty graphics are desired to the degree that people will happily buy new games regularly. This situation would not change for the worse in a free-software dominated world.
If a company can produce really good software that is different in kind to existing free software, then that too is certainly saleable. If there is nothing in the same class as the Google search engine, then there's nothing preventing Google from marketting its engine to companies in the same way as it is now. If there were something in the same league then it probably would be cheaper for those potential buyers to pay for the devlopment and refinement of the existing free software, especially as such development, drawing upon a very wide base of publicly available code in the free-software dominated world, would be much quicker.
I really can't see large scale free software availability destroying any software industry that currently exists and produces software that would not be available in a free software form.
The other benefit of such a world is of course that there is a lot of software that people can use, as software, for no cost. If it's good software (and for free software to dominate, it'll have to be at least in the same league as current commercial software) then aren't the users of that software getting more financially efficient use of their computers and their time?
I think you may also be misrepresenting Stallman's position some, but that is somewhat tangential to the original direction of the argument.
For reference, the Tyan Tiger MPX board used to ship with a USB 1.1 card, not a USB 2.0 card.
On the other hard, the latest revision of the board uses an updated version of the AMD chipset which resolves the bug, and thus has working on-board USB.
GPL is an enabling license. It allows people to do things with code that they usually are not allowed to do. It's not as enabling as the BSD license, but very deliberately so.
What is this possible danger you speak of?
A world with a lot of GPL software does not preclude commercial (non-GPL) development. It does make it harder for companies to sell crap. To me this seems like a good thing for all parties, save for those in the business of marketting sows' ears as silk purses. And good riddance to them.
The benefits are a much better educated programming community. Even if one is developing commercial software, one can learn from the wide availability of source in a GPL-rich world. Sure you can't copy that source, but it's not like you can now, anyway.
[Caveat: I used to work for the company that produced it, so I may be biased.]
The game "Powerslide" (an arcade-style racing game for the PC) had AI drivers which were indeed modelled with a neural net. The various net weights were 'bred' (GA techniques) to produce very good to poor AI 'mini-brains' (the poorer ones were explicitly bred to be played against in easy difficulty.) Sure, there were some hacks to make it all work well, but at the core, this was AI well-informed by the latest work in the field. Further, they really did drive pretty-much like one might expect a human to, even down to occasionally just wiping out or crashing.
The author states that/opt is obsolete, and that everything should use RPM and install in/usr. Maybe this is the ideal in a system where everything is binaries-only, but I firmly believe it is poor administration practice.
The RPM database is binary and fragile. Once it is corrupted, the data describing what belongs to what goes out the window. RPM-packages have to be trusted not to clobber existing files or make changes to configuration files that one wants left alone. The alternative is per-application directories and symlinks (or a long PATH variable); there are tools which automate this, such as stow. The advantage is that the file system is - or at least should be - the most stable thing in the system. One can just examine a symbolic link to see what package it belongs to. This makes removing and updating applications very easy, and also makes it easy to see if there are any links left around from older installations. Removing an application is typically as simple as removing the corresponding application directory.
RPMs which install in the/usr tree will require root priviledges, whereas applications that can work from a self-contained directory can be installed by a non-priviledged user in their own directory,
Also,/usr in principle can be mounted read-only. This will certainly slow down any attempts at installing software in it!
I have had Redhat's installer corrupt the RPM database on multiple occasions; and I've had to override the dependancy checking innumerable times in attempts to update packages under both Redhat and SuSE, thus rendering useless the other purported benefit of RPM. New software typically comes in source form before RPMs; and the RPMs that do become available are almost always going to be third-party ones that don't necessarily play well with your system. By the time a vendor-created RPM becomes available, the distribution version you are using is no longer actively supported, and you'll need 300MB of updates to other packages just to satisfy dependencies. I've been there, it's horrid.
A Cyrix 120MHz system, 96MB RAM. This used to have 64MB, and Gnome was slow enough to be annoying. At that point, I stuck to fvwm2 like any sane individual. Adding the extra 32MB made all the difference, and now Gnome is quite usable, even using gnome-terminal instead of xterm or rxvt. On this machine I'm not using sawfish, because the delay in bringing up window manager menus is too annoying.
A K6-3/400 machine, 256MB RAM. Again, this one used to have less memory. At 128MB, Gnome ran fine until I started Mozilla. Then the memory squabbles started to hurt. Quite liking Mozilla over Netscape 4 for a graphical browser, more RAM was the solution. This machine runs Gnome perfectly adequately.
One thing is that on both of these machines, I don't run Nautilus or GMC. Not a big fan of graphical file managers, I don't miss them. It's quite possible that they would slowficate the Gnome experience.
Oh, and another thing. Gnome 1.2, when I installed it, still looked like it could do with some sanding, and maybe another coat of paint. There were things left out of libraries, or in an inefficient way (thinking of some of the drawing routines.) These probably contributed to the memory usage and slowness of some graphical applications. Here's hoping that's all in the past now with Gnome 2 around the corner.
On a VIA chipset K6-3 system with a GeForce 2MX, the (closed-source) NVidia drivers are the least stable thing on my system. Sadly, when they go, they generally take out the machine.
If I don't run any OpenGL stuff, then my X sessions will last maybe 10 days before a crash. Running the 3d screensavers will reduce this to two or three days of stability. So typically I don't run anything 3d, which means I'd probably be better off just using the (non 3d-accelerated) drivers that come with XFree86.
I've also had a lot of problems with NVidia drivers under Windows 2000 -- the last two major releases will wedge the machine before the login window.
It's a 40mm x 40mm x 10mm 12VDC fan. I'm in the process of replacing it with a 5V Microcomp fan (MCKD0504PEB3-8) which is rated at 16dBA. It has about half the airflow, but I'm hoping it will still be sufficient.
For more information, or to see what others have done, have a look at the informative comment thread on the SV24 article at the Tech Report.
As the comment above languishing above at -1 says,
it did work great for the Russians.
In spite of a terrible economy and poor infrastructure, Russian technology was on par with or (in some areas) exceeded that of the United States. The USSR produced some of the finest mathematicians, engineers and scientists the world has seen.
When private companies fund and own research, it benefits directly only a small group of people. When research is publicly funded, it not only benefits the public at large directly, it also indirectly raises the power and efficiency of further research, as all the researches can draw upon this public body of knowledge. The efficiency gain scales super-linearly.
The US has a large population, pays well for skilled, technical work, and is very influential in a number of technical and academic fields. So if someone is in another country and seeks to gain money, experience, reputation, time spent in the US can be very valuable.
Of course, once these things have been acquired, many people move elsewhere or return to their home country, where the quality of life - in every other regard - can be superior. Especially now that they are more secure in their career and finances.
So it comes down to cost/benefit. Endure the sometimes nasty aspects of US life and society in exchange for money and experience. When these are no longer such a high priority, move on. It's a bit like the way some notable US companies move their production into countries with cheap labour and lax labour laws... but in reverse.
With a "built-in media player, based on Sorenson Media's video player" we're not going to see a source-available version any time soon. In the past Flash has been a security liability through buffer overruns in the player. There's no way they can be held accountable for them if there are no alternatives.
Executable material in web pages is very rarely necessary. When it is though there's that language, um, what was it called? Java? I hear some people code in that already.
Flash has been one of the suckiest aspects of the web in recent years. Given that it so counters accessibility, usability, cross-platformedness, and indexability, there is no way it can possibly be a good thing for web pages. It is the exact opposite of good for web pages.
Flash developers are being smarter about how they're using Flash.
There's no smart way of using Flash as part of the web. You can use HTTP as a transport mechanism for your closed Flash application, but you can use HTTP for anything. There's more to being part of the web than being served over port 80.
Flash should be thrown out as a web application platform. Just tossed. Don't use it. The record shows that most flash is expensive, bandwidth sucking, usability crushing crud, which is all the more frustrating for its complete lack of necessity. The only Flash I've seen that was not so were animationts where the animations were themselves the content. In this situation Flash is a glorified video codec, and if that's all it was ever used for, things wouldn't be so bad.
It's hard to see how Flash could be fixed. One could open up the format, but that doesn't change the fact that it's sucky for the web. If a site uses Flash in a way that works well without it, why bother with it in the first place? If it doesn't degrade gracefully, then congratulations, you have made a site that throws away most of what makes the web actually useful.
Now, if it's related to Disney's business, and done on their time, then it should belong to Disney.
Why even this? The whole work-for-hire thing is crazy. Did Disney create that character design? Only legally. At the end of the day, some individual or a small group did so. Yet they don't even have moral rights to their work!
When one works in a creative capacity for someone else, clearly they should be granted the right to copy and make derivative works and so on. But they should not be granted THE Copyright.
What an unfortunate opinion piece. For someone extolling the virtues of a scientific approach to HCI, it's almost criminal to simultaneously engage in fatuous argument. It colours the topic by association. Why is it bad argument?
Firstly, there is the fallacy that there are only two options. The opposite of 'no configurability' is not 'everything is seperately configurable'. There is a middle ground that is being excluded by omission. This middle ground contains the most sensible option: one could apply one configurable interface across all applications that would thereby provide a consistent interface to the user in question. So excluding it is disingenuous.
Secondly, there is the infamous strawman argument. Configurability taken to extremes allows poor interfaces to be configured. Configuring someone's machine to show text as red on red doesn't demonstrate that the concept of configurability is bad - it just demonstrates that one can make bad choices. Or in this case, that Jef Raskin can be a bastard to one of his clients.
The other flaws in the argument fall into one of these two categories. For example, that there is only a choice between (1) a single customisable interface across a platform, and (2) other users of a machine being stuck with an unfamiliar interface. As other commenters have noted, this is silly. The clear sensible option is per-user preferances, and ideally ones that migrate with the user.
Lastly he argues that adding interface customizability enlarges applications. This is certainly true. He naturally fails to mention that this is a trade-off against the possibility that the user of an application may be able to work more efficiently as a result, if they make the interface more suited to themselves.
As with all these sorts of things, it's tedious and sometimes difficult to sort out the fallacious arguments from the valid, spot the omitted facts, and distinguish between truth and spin. There are some valid points buried in that rubbish, but the Jef and the interviewer do their readers no favours by using such points as support for an argument that is deceptive and unreasonable.
How about some intellectual honesty? Or is that just too much to ask?
Re:Corrections, pointers, and cautions
on
Understanding NFS
·
· Score: 3, Informative
The "soft" mount option used often to be called the "corrupt" option.
The problem is that programs rarely check to see if a write() fails after a successful open(). When the file system moves around under them, they can fail to write important data in blissful ignorance. This can lead to files whose contents are essentially broken.
The fault doesn't really lie with NFS, so much as with the lage body of code which assumes write() calls to a file are more reliable than NFS soft-mounted file systems allow.
Generally speaking, using soft mount is asking for trouble.
Solaris may be more scalable, but more stable? It depends very much on the hardware.
To pull an example out of the air, I don't think I've ever seen a stable Solaris on the Sparc Ultra 5 (their 'cheap' IDE-based workstation.) I've also witnessed some really nasty wedging with LDAP authentication and panics on Sun Ultrasparc machines fighting it out with Sun-branded RAID arrays under load.
Maybe the latest version of Solaris is completely unlike its predecessors, but it seems a little unlikely.
Some versions of the Linux kernel, together with XFree, GNU software and other tools, have been exceptionally stable on certain combinations of x86-based PC hardware. Given that Sun control their own hardware, it seems unfair to criticise Linux's stability when compared with Solaris.
The current system for starters isn't too bad - the configuration files for important system tools are typically well documented (in man pages if nowhere else), and aren't too hard to edit in a text editor. Certainly there is a problem with the use of automated GUI tools for system configuration, but I can't really see why GUI tools are so important.
Consistency though would be a nice thing, if only so that as more programs are used and require configuration, we don't all have to learn more and more ad hoc configuration schemes. There is the potential for the current system to get well out of hand. Consistency is nice from an aesthetic point of view - ad hocery is rarely pretty.
Tools such as linuxconf or webmin don't help the problem, they just obscure it. Often badly! (Don't get me started on linuxconf, ugh!)
The earlier suggestions of XML, or a recognised subset of XML, together with XML schema to describe the formats, seem ideal as far as file formats go:
It's standard and well-documented.
There are a large number of parsers that work with a useful large subset of XML, for many platforms and languages.
In a pinch, it's not hard to write a quick and dirty and correct-enough parser from scratch on an ad hoc basis, to parse your own particular XML-based configuration files.
It's human editable (or should be, if used wisely).
It is rich enough to encompass all the text-format configuration files currently in common use (under the Linux-based operating systems I know of at least).
The big problem of course is inertia: changing configuration files is a big change! Personally, I think the cost though would be worth it in the long term.
The important thing to me is that there is no API specified as mandatory. While a standard API for accessing and manipulating configuration data would be nice, requiring it to be used will not only make adoption of a standard config format slower and harder, but will also limit software developers to the tools for which the API has an implementation. I'd go for:
Use XML + schema as the mandatory config file format in the new scheme.
Have a preferred mechanism for signalling to applications that configuration data has changed (eg SIGHUP) so that changes can be made atomically.
Provide an API for manipulation of config data, but only as a convenience to developers and automated config tools.
I also agree with the earlier comment promoting the use of ~/etc over dot-files. Makes good sense! Again, it's only inertia that will make such a change difficult. Though if other changes are going through... in for a penny, in for a pound!
Lastly, whatever scheme is adopted, it seems to me essential that there be some flexibility in where the configuration files are located. Standard places are important, but there must also be some way to say to an application that their config data is in/usr/local/etc, or in/opt/package-name/etc, or wherever. This is necessary for sane package isolation and management, especially if not all software on a system is maintained by someone with superuser priveleges.
...If we want a chance of getting Unix to the unwashed masses -- to enlighten them a bit, maybe to get them to do the right thing.
Much better in my view is to wash them.
While there is no excuse of course for needlessly hard or complex configuration files and such, when simplification comprimises usability, security and capability it has gone too far. Rather than dumb-down the software, let's encourage people to actually learn about the tool they're using. Perhaps once people understand what security is and why it's important, they might finally start adopting security-aware proceedures.
er, guns do hurt people. That and hunting are indeed their primary purposes.
Unsurprisingly there are fewer gun deaths per capita in those democracies where gun use is restricted.
Gun laws won't stop the sole loony with an illegally owned gun doing the rampage thing. But such loons aren't the ones responsible for the amazingly large number of people who get shot in the US every year.
However you may feel about gun control, comparing them to a device that may have application in unauthorized copying of software is ludicrous.
Slashdot Mirror
Reading their technology explanation, the idea certainly seems reasonable enough! The trick being of course in the manufacturing of the two very close but seperated layers.
If I understood their physics-for-dummies explanation correctly, the principle relies on two metals separated by a very thin gap; a potential difference across the plates encourages tunneling of electrons across the gap, carrying heat with them.
IANAP, but I'm sure someone here is: doesn't vibration at the atomic scale in some crystalline medium also act like a particle? Can these guys also tunnel across gaps, or is their weird quantum nature restricted to the single medium they're expressed in? If they could tunnel, I would have thought that as the heat differential across the plates increased, their tunneling would also increase, acting as a break on the process and bringing about an equilibrium situation (temperature differential vs. potential differential.) Or is the mechanism for equilibrium simply black-body radiation across the gap, or similar?
What sort of temperature differentials are possible through a device like this? Is it only limited by mechanical constraints?
Hope these thoughts aren't entirely moronic.
That's one hell of a rejoinder to a throw-away comment.
More specifically: there are much larger margins on server-targeted hardware, such as tape drives, than there is in the desktop arena. While 5-10% margins are common at the retail level for consumer hardware, tape systems seem to start at 20% and go up from there.
Even acknowledging the fact that these are mechanical devices and so will naturally not benefit so greatly from the price drops in other computer hardware, tape backup prices have barely fallen at all in the last 4 years. As higher capacities and speeds are introduced, they just come out at higher and higher pricepoints.
There doesn't need to be an organised cabal - when you have a market which is willing to pay these prices, and where there are often established long-term relationships between the buyers and vendors, it's unsurprising that there hasn't been the same downward pressure on prices. Unlike in consumer hardware, where there is typically little brand loyalty and price-competition is fierce.
Final concrete example: getting SCSI hardware in an external enclosure typically costs about 12% more than when it is bare. At the cheap end, it's about what you'd expect to pay for a decent enclosure. At the expensive end, it's about 3 or 4 times the retail cost of a similar enclosure. Where's the competition driving prices down here?
Oh, and don't be so quick to call people retards. It's rude on a number of levels.
I think that is what is usually called a straw-man argument.
Few if any people are promoting the idea of electric-only cars powered by traditional batteries, and refilled by plugging it into the wall socket. For the very reasons you describe, it would be expensive and ineffective.
As described in the article, and often on slashdot, the idea is to have a fuel cell in the car which uses hydrogen very efficiently. The problem then becomes a matter of storing and generating the hydrogen. Storing it (and there are a number of options) is expensive but possible. The fact that there are working experimental hydrogen-based cars demonstrates this. It is a one-off cost though, so shouldn't be taken too seriously.
Generating the hydrogen can be done at the site of another form of power generation. Even if this is done with coal and oil plants (which of course is a very poor way to create power to begin with when compared with (say) natural gas) one eliminates the losses due to power transmission etc. Further, the pollution that eminates from the burning of fossil fuels is much more easily contained at a single site (like a power station) than it is when it's generated by 234723849 cars.
There are much more efficient ways of generating hydrogen though, from natural gas or methane directly, which completely bypass the very dirty and relatively inefficient coal and oil power production systems.
The only reason why hybrid cars are the best solution right now, is that there is a lack of a hydrogen supply infrastructure. Fix that, and hydrogen as energy storage comes into its own.
Again, as described in the article, a promising avenue to this is through converting local bus services to hydrogen-based, which even in the absence of an established hydrogen infrastructure, can then be cheaper to run. This in turn creates a market for distribution,
I'm going to try and summarize your argument in order to attack it, but I may be misrepresenting it; if so, please accept my apologies in advance!
The key point seems to be if there is a large amount of no-charge freely-copyable software available which is adequate for most tasks, then it will be impossible for companies to economically produce very good commercial software. The reason for this being that too many people will be happy to make do with the free alternatives, and so the cost of production of the really good software could never be recouped.
This may indeed be a force towards the production of less commercial software. On the other hand, the availability of a wide code-base that is freely available for use in free software means that the cost of development of new free software is also made that much lower. If the market ever reaches such a state (and I admit to being highly sceptical that it will while the current IP regime remains in place), then in those areas where free and commercial software are competing, the same force that makes the commercial software less viable makes it more likely that the free software can be cheaply and easily shaped to fit the task.
There are some areas where such competition seems less likely, such as those where there is a large amount of non-code labour required. The primary example here is that of modern computer games. Here novelty and pretty graphics are desired to the degree that people will happily buy new games regularly. This situation would not change for the worse in a free-software dominated world.
If a company can produce really good software that is different in kind to existing free software, then that too is certainly saleable. If there is nothing in the same class as the Google search engine, then there's nothing preventing Google from marketting its engine to companies in the same way as it is now. If there were something in the same league then it probably would be cheaper for those potential buyers to pay for the devlopment and refinement of the existing free software, especially as such development, drawing upon a very wide base of publicly available code in the free-software dominated world, would be much quicker.
I really can't see large scale free software availability destroying any software industry that currently exists and produces software that would not be available in a free software form.
The other benefit of such a world is of course that there is a lot of software that people can use, as software, for no cost. If it's good software (and for free software to dominate, it'll have to be at least in the same league as current commercial software) then aren't the users of that software getting more financially efficient use of their computers and their time?
I think you may also be misrepresenting Stallman's position some, but that is somewhat tangential to the original direction of the argument.
For reference, the Tyan Tiger MPX board used to ship with a USB 1.1 card, not a USB 2.0 card.
On the other hard, the latest revision of the board uses an updated version of the AMD chipset which resolves the bug, and thus has working on-board USB.
GPL is an enabling license. It allows people to do things with code that they usually are not allowed to do. It's not as enabling as the BSD license, but very deliberately so.
What is this possible danger you speak of?
A world with a lot of GPL software does not preclude commercial (non-GPL) development. It does make it harder for companies to sell crap. To me this seems like a good thing for all parties, save for those in the business of marketting sows' ears as silk purses. And good riddance to them.
The benefits are a much better educated programming community. Even if one is developing commercial software, one can learn from the wide availability of source in a GPL-rich world. Sure you can't copy that source, but it's not like you can now, anyway.
[Caveat: I used to work for the company that produced it, so I may be biased.] The game "Powerslide" (an arcade-style racing game for the PC) had AI drivers which were indeed modelled with a neural net. The various net weights were 'bred' (GA techniques) to produce very good to poor AI 'mini-brains' (the poorer ones were explicitly bred to be played against in easy difficulty.) Sure, there were some hacks to make it all work well, but at the core, this was AI well-informed by the latest work in the field. Further, they really did drive pretty-much like one might expect a human to, even down to occasionally just wiping out or crashing.
The author states that /opt is obsolete, and that everything should use RPM and install in /usr. Maybe this is the ideal in a system where everything is binaries-only, but I firmly believe it is poor administration practice.
The RPM database is binary and fragile. Once it is corrupted, the data describing what belongs to what goes out the window. RPM-packages have to be trusted not to clobber existing files or make changes to configuration files that one wants left alone. The alternative is per-application directories and symlinks (or a long PATH variable); there are tools which automate this, such as stow. The advantage is that the file system is - or at least should be - the most stable thing in the system. One can just examine a symbolic link to see what package it belongs to. This makes removing and updating applications very easy, and also makes it easy to see if there are any links left around from older installations. Removing an application is typically as simple as removing the corresponding application directory.
RPMs which install in the /usr tree will require root priviledges, whereas applications that can work from a self-contained directory can be installed by a non-priviledged user in their own directory,
Also, /usr in principle can be mounted read-only. This will certainly slow down any attempts at installing software in it!
I have had Redhat's installer corrupt the RPM database on multiple occasions; and I've had to override the dependancy checking innumerable times in attempts to update packages under both Redhat and SuSE, thus rendering useless the other purported benefit of RPM. New software typically comes in source form before RPMs; and the RPMs that do become available are almost always going to be third-party ones that don't necessarily play well with your system. By the time a vendor-created RPM becomes available, the distribution version you are using is no longer actively supported, and you'll need 300MB of updates to other packages just to satisfy dependencies. I've been there, it's horrid.
I run Gnome on some 'old' systems:
One thing is that on both of these machines, I don't run Nautilus or GMC. Not a big fan of graphical file managers, I don't miss them. It's quite possible that they would slowficate the Gnome experience.
Oh, and another thing. Gnome 1.2, when I installed it, still looked like it could do with some sanding, and maybe another coat of paint. There were things left out of libraries, or in an inefficient way (thinking of some of the drawing routines.) These probably contributed to the memory usage and slowness of some graphical applications. Here's hoping that's all in the past now with Gnome 2 around the corner.
On a VIA chipset K6-3 system with a GeForce 2MX, the (closed-source) NVidia drivers are the least stable thing on my system. Sadly, when they go, they generally take out the machine.
:)
If I don't run any OpenGL stuff, then my X sessions will last maybe 10 days before a crash. Running the 3d screensavers will reduce this to two or three days of stability. So typically I don't run anything 3d, which means I'd probably be better off just using the (non 3d-accelerated) drivers that come with XFree86.
I've also had a lot of problems with NVidia drivers under Windows 2000 -- the last two major releases will wedge the machine before the login window.
My next card will probably be a Radeon
I can second the PS fan noise is the problem!
It's a 40mm x 40mm x 10mm 12VDC fan. I'm in the process of replacing it with a 5V Microcomp fan (MCKD0504PEB3-8) which is rated at 16dBA. It has
about half the airflow, but I'm hoping it will
still be sufficient.
For more information, or to see what others have done, have a look at the informative comment thread on the SV24 article at the Tech Report.
As the comment above languishing above at -1 says, it did work great for the Russians.
In spite of a terrible economy and poor infrastructure, Russian technology was on par with or (in some areas) exceeded that of the United States. The USSR produced some of the finest mathematicians, engineers and scientists the world has seen.
When private companies fund and own research, it benefits directly only a small group of people. When research is publicly funded, it not only benefits the public at large directly, it also indirectly raises the power and efficiency of further research, as all the researches can draw upon this public body of knowledge. The efficiency gain scales super-linearly.
Mainly for the money and for experience.
... but in reverse.
The US has a large population, pays well for skilled, technical work, and is very influential in a number of technical and academic fields. So if someone is in another country and seeks to gain money, experience, reputation, time spent in the US can be very valuable.
Of course, once these things have been acquired, many people move elsewhere or return to their home country, where the quality of life - in every other regard - can be superior. Especially now that they are more secure in their career and finances.
So it comes down to cost/benefit. Endure the sometimes nasty aspects of US life and society in exchange for money and experience. When these are no longer such a high priority, move on. It's a bit like the way some notable US companies move their production into countries with cheap labour and lax labour laws
With a "built-in media player, based on Sorenson Media's video player" we're not going to see a source-available version any time soon. In the past Flash has been a security liability through buffer overruns in the player. There's no way they can be held accountable for them if there are no alternatives.
Executable material in web pages is very rarely necessary. When it is though there's that language, um, what was it called? Java? I hear some people code in that already.
Flash has been one of the suckiest aspects of the web in recent years. Given that it so counters accessibility, usability, cross-platformedness, and indexability, there is no way it can possibly be a good thing for web pages. It is the exact opposite of good for web pages.
There's no smart way of using Flash as part of the web. You can use HTTP as a transport mechanism for your closed Flash application, but you can use HTTP for anything. There's more to being part of the web than being served over port 80.Flash should be thrown out as a web application platform. Just tossed. Don't use it. The record shows that most flash is expensive, bandwidth sucking, usability crushing crud, which is all the more frustrating for its complete lack of necessity. The only Flash I've seen that was not so were animationts where the animations were themselves the content. In this situation Flash is a glorified video codec, and if that's all it was ever used for, things wouldn't be so bad.
It's hard to see how Flash could be fixed. One could open up the format, but that doesn't change the fact that it's sucky for the web. If a site uses Flash in a way that works well without it, why bother with it in the first place? If it doesn't degrade gracefully, then congratulations, you have made a site that throws away most of what makes the web actually useful.
On MOs ... I'm bitter too.
2.3GB on a 3.5" form factor? Only four times slower than a hard disk, and just as reliable?
And we're still using floppies.
When one works in a creative capacity for someone else, clearly they should be granted the right to copy and make derivative works and so on. But they should not be granted THE Copyright.
I'm not holding my breath though.
What an unfortunate opinion piece. For someone extolling the virtues of a scientific approach to HCI, it's almost criminal to simultaneously engage in fatuous argument. It colours the topic by association. Why is it bad argument?
The other flaws in the argument fall into one of these two categories. For example, that there is only a choice between (1) a single customisable interface across a platform, and (2) other users of a machine being stuck with an unfamiliar interface. As other commenters have noted, this is silly. The clear sensible option is per-user preferances, and ideally ones that migrate with the user.
Lastly he argues that adding interface customizability enlarges applications. This is certainly true. He naturally fails to mention that this is a trade-off against the possibility that the user of an application may be able to work more efficiently as a result, if they make the interface more suited to themselves.
As with all these sorts of things, it's tedious and sometimes difficult to sort out the fallacious arguments from the valid, spot the omitted facts, and distinguish between truth and spin. There are some valid points buried in that rubbish, but the Jef and the interviewer do their readers no favours by using such points as support for an argument that is deceptive and unreasonable.
How about some intellectual honesty? Or is that just too much to ask?
The "soft" mount option used often to be called the "corrupt" option.
The problem is that programs rarely check to see if a write() fails after a successful open(). When the file system moves around under them, they can fail to write important data in blissful ignorance. This can lead to files whose contents are essentially broken.
The fault doesn't really lie with NFS, so much as with the lage body of code which assumes write() calls to a file are more reliable than NFS soft-mounted file systems allow.
Generally speaking, using soft mount is asking for trouble.
Solaris may be more scalable, but more stable? It depends very much on the hardware.
To pull an example out of the air, I don't think I've ever seen a stable Solaris on the Sparc Ultra 5 (their 'cheap' IDE-based workstation.) I've also witnessed some really nasty wedging with LDAP authentication and panics on Sun Ultrasparc machines fighting it out with Sun-branded RAID arrays under load.
Maybe the latest version of Solaris is completely unlike its predecessors, but it seems a little unlikely.
Some versions of the Linux kernel, together with XFree, GNU software and other tools, have been exceptionally stable on certain combinations of x86-based PC hardware. Given that Sun control their own hardware, it seems unfair to criticise Linux's stability when compared with Solaris.
The current system for starters isn't too bad - the configuration files for important system tools are typically well documented (in man pages if nowhere else), and aren't too hard to edit in a text editor. Certainly there is a problem with the use of automated GUI tools for system configuration, but I can't really see why GUI tools are so important.
Consistency though would be a nice thing, if only so that as more programs are used and require configuration, we don't all have to learn more and more ad hoc configuration schemes. There is the potential for the current system to get well out of hand. Consistency is nice from an aesthetic point of view - ad hocery is rarely pretty.
Tools such as linuxconf or webmin don't help the problem, they just obscure it. Often badly! (Don't get me started on linuxconf, ugh!)
The earlier suggestions of XML, or a recognised subset of XML, together with XML schema to describe the formats, seem ideal as far as file formats go:
- It's standard and well-documented.
- There are a large number of parsers that work with a useful large subset of XML, for many platforms and languages.
- In a pinch, it's not hard to write a quick and dirty and correct-enough parser from scratch on an ad hoc basis, to parse your own particular XML-based configuration files.
- It's human editable (or should be, if used wisely).
- It is rich enough to encompass all the text-format configuration files currently in common use (under the Linux-based operating systems I know of at least).
The big problem of course is inertia: changing configuration files is a big change! Personally, I think the cost though would be worth it in the long term.The important thing to me is that there is no API specified as mandatory. While a standard API for accessing and manipulating configuration data would be nice, requiring it to be used will not only make adoption of a standard config format slower and harder, but will also limit software developers to the tools for which the API has an implementation. I'd go for:
I also agree with the earlier comment promoting the use of ~/etc over dot-files. Makes good sense! Again, it's only inertia that will make such a change difficult. Though if other changes are going through ... in for a penny, in for a pound!
Lastly, whatever scheme is adopted, it seems to me essential that there be some flexibility in where the configuration files are located. Standard places are important, but there must also be some way to say to an application that their config data is in /usr/local/etc, or in /opt/package-name/etc, or wherever. This is necessary for sane package isolation and management, especially if not all software on a system is maintained by someone with superuser priveleges.
While there is no excuse of course for needlessly hard or complex configuration files and such, when simplification comprimises usability, security and capability it has gone too far. Rather than dumb-down the software, let's encourage people to actually learn about the tool they're using. Perhaps once people understand what security is and why it's important, they might finally start adopting security-aware proceedures.
To summarise: smarter people, not dumber tools.
er, guns do hurt people. That and hunting are indeed their primary purposes.
Unsurprisingly there are fewer gun deaths per capita in those democracies where gun use is restricted.
Gun laws won't stop the sole loony with an illegally owned gun doing the rampage thing. But such loons aren't the ones responsible for the amazingly large number of people who get shot in the US every year.
However you may feel about gun control, comparing them to a device that may have application in unauthorized copying of software is ludicrous.