Except for their peripherals department, which makes very good mice, keyboards, and cool joysticks. Give credit where it's due.
Microsoft's peripherals are nice, really. Tho it's unlikely they'll be putting Logitech out of business anytime soon, it's one of the brighter spots in an otherwise bleak record of expansion.
It does not matter that M$ doesn't own a market, the minute they set their eyes on one, the current market leader (weither (sp?) it is a company or an {open} technology) is toast. Think about the state of the OA software market 10+ years ago, web browsers 5 years ago, server market, etc. M$ has the will and the means to conquer any market they want to own. Remember that.
Bullshit. Really. Apache is still beating IIS in market share and always has. The PS2 is still clobbering the X-Box. The PalmOS is still demolishing the PocketPC. WebTV has been toast for some time. Heck, the only places Microsoft *have* been successful are Windows (due to a desktop monopoly), Explorer (due to leveraging the previous monopoly to squash Netscape) and Office (due mostly to locked-in data formats). Outside of the narrowly-defined desktop realm, Microsoft is one vast litany of failures.
One more way for Microsoft to lock up artist works in their own file formats. How long before studios decide to release Windows only DVD's rather than bother reencoding the movies?
Considering the staggering total
of existing DVD players on the market, it's unlikely that a consumer electronics non-giant like Microsoft will be able to foist a new "standard" on the market anytime soon. It'll be a few years yet before the DVD momentum subsides and enough people have the high-definition equipment necessary to even consider putting anything else on the market.
No way. Moving metadata out of the file and into the FS is a *great* idea. Keep the actual 'data', the stuff that is critical, in the file for transferring them around. If people keep compatibility as their number one goal, we'll never get anything new.
Compatibility is important, but avoiding lossage is the most important thing of all when storing data. Imagine, as an example, I store the album titles of all my ripped songs as filesystem-specific metadata rather than in the files themselves. If, at a later date, I transfer them to another system without support for that metadata, I will lose that data and won't get it back - a bit like losing one's file ownership by untarring them on Windows. By keeping the metadata in the file, even if the OS/player/viewer/whatever doesn't support it, I won't lose that data simply by moving it between various systems with varying levels of compatibility.
I don't necessarily think that putting the data in/on the file makes any sense either, we have to deal with legacy file formats which have no provision for such tampering, some of which will not work with additional data added to the end, which is the usual suggestion in these cases.
Legacy data formats are a problem when it comes to metadata, especially for non-open formats that haven't evolved much over the years (mp3's ID tags are something of a hack, for example). In those cases, the best solutions is probably some sort of wrapper file format around the original data - a bit like how ogg is a wrapper for raw vorbis audio files. But, that would require a change in the way the legacy format is handled. In those cases, there probably isn't a perfect solution:(
Rather than putting the metadata in the file (we want to be able to store arbitrary metadata for any file, right?) we should be putting it in the filesystem alongside the file.
The problem is that storing the metadata seperately is inherently fragile and will need to be standardized *everywhere* in order for it to work at all. Otherwise, all the precious metadata I've assigned to file X would be lost if system Foo is unable to extract it from system Bar's archive files (which would contain such data). Plus, even our archive formats would have to be adjusted to handle the switch.
So of the evils of where to store metadata, I think keeping it in the file but having the system able to extract/cache it is the lesser of the two.
Re:Meta data may be coming
on
A Better Finder?
·
· Score: 2, Interesting
In order to support some aspects of this finder filesystem meta data must be supported in a more complete way than it is at the moment. You don't want the system to have to trawl through the tags in every MP3 file everytime it lists the folder contents (that would make it even slower:).
System-specific metadata should be left at the filesystem level (file permissions, ownership, etc.) but file-specific metadata shouldn't be moved out of the file. Keeping one's data files as one big block of data is a Good Thing, especially when transferring them around between systems or over the internet. Having said that, I do think that the OS should be willing and able to cache that info so that users can sort their mp3s by ID3 tags (for example) without a nasty performance hit.
Redhat most certainly did bundle commercial applications with their product line at one point in time.
I seem to recall some of the early 6.x series distros shipping with non-freely-distributable stuff like Acrobat Reader and game demos also. But none of that wound up on Red Hat's FTP site for people to download and was clearly labeled as non-distributable, IIRC. And, I think the "Advanced Server" stuff they sell also has proprietary stuff alongside the regular distro discs. But the important thing is that the stuff you and I can download off Red Hat's site is free to redistribute and likely always will be.
Maybe I'm missing something but doesn't the piece you quoted explicitly say that there _are_ "certain image files" that may not be freely redistributed?
Red Hat's logo and bluecurve theme are protected under trademark law and their use is mentioned on Red Hat's site. But distributing them is okay under fair use so long as the distro isn't modified from the original (in which case you'd have to call it something other than "Red Hat").
Last I heard, the redhat cds contained proprietary software. They do contain plenty of GPL'd stuff, but redhat adds a bunch of non-GPL'd things in. If I remember right, they leave the non-gpl stuff off the first cd, so the first cd would be perfectly fine and happy to distribute on bittorrent. However, if any of the iso's contain NON-GPL'd NON-BSD-licensed software, they no longer can be distributed as if there's a huge THIS IS ALL GPL sticker on it.
That's not true, and has never been true. Here is a portion of the EULA from Disc 3 of RH 8.0:
Most of the Linux Programs are licensed
pursuant to an open source EULA that permits you to copy, modify, and redistribute the software, in both source code and binary code forms. With the exception
of the content of certain image files identified below, the remaining Linux Programs are freeware or have been placed in the public domain.
In short, there is nothing in the personal, downloadable editions of the Red Hat distribution that is not GPLed, open sourced or otherwise not free to redistribute.
OOP is totally useless for the web script itself, which lacks any logical object to orient your programming around
Eh? Isn't the HTML tag a good logical object to base programming around? By pointing an HTML form input object to a CGI form data object, you could create form objects capable of not only printing themselves (such as <input type=text maxlength=20> from a TextInput object) but also automatically ensuring the submitted form's values are within specified bounds (i.e. cropping off a posted value greater than 20 characters) and that's just for starters.
Of course, having *all* of one's HTML tags as objects is likely to pose a huge performance hit, but I've found the technique useful in small doses for encapsulation purposes.
I have to agree; there are way to many "dead" projects on SF. What the need is both a way to kill a project, and an automated culler. If there has been no activity in the past six months, then send an email to the project owner. If there is no response, then kill the project. Easy.
If a project hasn't released any files/code, and isn't hosting a page, I'd say killing it is in order if the maintainer can't be found and/or bothered to respond to an "are you alive" message. But if something has been released but has no maintainer, I think a better idea is to build a database of "orphaned" projects that more active maintainers can pick up or acquire code from. Then, if *that* doesn't result in any activity (no new maintainer, and no file downloads) for 12 months or so, I'd say that un-hosting the files is a good idea.
Fully indexed, with user comments... I often find new techniques while searching for something completely unrelated. I think the great documentation is one of the reasons why MySQL has taken off, it's just so easy to learn.
Furthermore, look at the dead-tree documentation available for each. Not only are there more MySQL books available than PostgreSQL ones, but the MySQL ones tend to be larger. For example, the New Riders MySQL book is over 400 pages longer than the PostgreSQL one - and their MySQL title isn't exactly brimming with filler. I'm convincesd PostgreSQL adoption will lag behind MySQL until more/better docs show up so people can learn it and its capabilities better.
I recommend the ROX Filer. It's a lot faster and lighter than Nautilus, it's both tweakable and intuitive, and it's not a clone of some other file manager. Its only drawback is that more distros don't include it.
Slashdot Mirror
Microsoft's peripherals are nice, really. Tho it's unlikely they'll be putting Logitech out of business anytime soon, it's one of the brighter spots in an otherwise bleak record of expansion.
Bullshit. Really. Apache is still beating IIS in market share and always has. The PS2 is still clobbering the X-Box. The PalmOS is still demolishing the PocketPC. WebTV has been toast for some time. Heck, the only places Microsoft *have* been successful are Windows (due to a desktop monopoly), Explorer (due to leveraging the previous monopoly to squash Netscape) and Office (due mostly to locked-in data formats). Outside of the narrowly-defined desktop realm, Microsoft is one vast litany of failures.
But will anyone be able to tell the difference?
Considering the staggering total of existing DVD players on the market, it's unlikely that a consumer electronics non-giant like Microsoft will be able to foist a new "standard" on the market anytime soon. It'll be a few years yet before the DVD momentum subsides and enough people have the high-definition equipment necessary to even consider putting anything else on the market.
Compatibility is important, but avoiding lossage is the most important thing of all when storing data. Imagine, as an example, I store the album titles of all my ripped songs as filesystem-specific metadata rather than in the files themselves. If, at a later date, I transfer them to another system without support for that metadata, I will lose that data and won't get it back - a bit like losing one's file ownership by untarring them on Windows. By keeping the metadata in the file, even if the OS/player/viewer/whatever doesn't support it, I won't lose that data simply by moving it between various systems with varying levels of compatibility.
Legacy data formats are a problem when it comes to metadata, especially for non-open formats that haven't evolved much over the years (mp3's ID tags are something of a hack, for example). In those cases, the best solutions is probably some sort of wrapper file format around the original data - a bit like how ogg is a wrapper for raw vorbis audio files. But, that would require a change in the way the legacy format is handled. In those cases, there probably isn't a perfect solution :(
The problem is that storing the metadata seperately is inherently fragile and will need to be standardized *everywhere* in order for it to work at all. Otherwise, all the precious metadata I've assigned to file X would be lost if system Foo is unable to extract it from system Bar's archive files (which would contain such data). Plus, even our archive formats would have to be adjusted to handle the switch.
So of the evils of where to store metadata, I think keeping it in the file but having the system able to extract/cache it is the lesser of the two.
System-specific metadata should be left at the filesystem level (file permissions, ownership, etc.) but file-specific metadata shouldn't be moved out of the file. Keeping one's data files as one big block of data is a Good Thing, especially when transferring them around between systems or over the internet. Having said that, I do think that the OS should be willing and able to cache that info so that users can sort their mp3s by ID3 tags (for example) without a nasty performance hit.
I seem to recall some of the early 6.x series distros shipping with non-freely-distributable stuff like Acrobat Reader and game demos also. But none of that wound up on Red Hat's FTP site for people to download and was clearly labeled as non-distributable, IIRC. And, I think the "Advanced Server" stuff they sell also has proprietary stuff alongside the regular distro discs. But the important thing is that the stuff you and I can download off Red Hat's site is free to redistribute and likely always will be.
Red Hat's logo and bluecurve theme are protected under trademark law and their use is mentioned on Red Hat's site. But distributing them is okay under fair use so long as the distro isn't modified from the original (in which case you'd have to call it something other than "Red Hat").
That's not true, and has never been true. Here is a portion of the EULA from Disc 3 of RH 8.0:
In short, there is nothing in the personal, downloadable editions of the Red Hat distribution that is not GPLed, open sourced or otherwise not free to redistribute.Eh? Isn't the HTML tag a good logical object to base programming around? By pointing an HTML form input object to a CGI form data object, you could create form objects capable of not only printing themselves (such as <input type=text maxlength=20> from a TextInput object) but also automatically ensuring the submitted form's values are within specified bounds (i.e. cropping off a posted value greater than 20 characters) and that's just for starters. Of course, having *all* of one's HTML tags as objects is likely to pose a huge performance hit, but I've found the technique useful in small doses for encapsulation purposes.
If a project hasn't released any files/code, and isn't hosting a page, I'd say killing it is in order if the maintainer can't be found and/or bothered to respond to an "are you alive" message. But if something has been released but has no maintainer, I think a better idea is to build a database of "orphaned" projects that more active maintainers can pick up or acquire code from. Then, if *that* doesn't result in any activity (no new maintainer, and no file downloads) for 12 months or so, I'd say that un-hosting the files is a good idea.
Or perhaps Pyrite.
(though I know that's not an element)
The R1 DVDs have no red tint.
X11 is old and therefore needs to be replaced - much like the wheel.
No, but I do know a couple of former Atari employees that now work for Apple. I think they wrote "Breakout".
If it'll make you happy.
Pure plagiarism. If one's going to steal old articles, the least one can do is reference the original.
Perhaps some folks that don't like running proprietary OSes on their hardware.
Looks like they do already.
Furthermore, look at the dead-tree documentation available for each. Not only are there more MySQL books available than PostgreSQL ones, but the MySQL ones tend to be larger. For example, the New Riders MySQL book is over 400 pages longer than the PostgreSQL one - and their MySQL title isn't exactly brimming with filler. I'm convincesd PostgreSQL adoption will lag behind MySQL until more/better docs show up so people can learn it and its capabilities better.
I recommend the ROX Filer. It's a lot faster and lighter than Nautilus, it's both tweakable and intuitive, and it's not a clone of some other file manager. Its only drawback is that more distros don't include it.
How about this thing?
That's because the rest were moderated down into oblivion ;)
It looks like the second worst challenge is correct apostraphe usage. I'm amazed that a company president uses "Memo's" to mean "memos". Scary.