If both FF and IE display the webpages they want, and the user don't care about anything else... in what way is FF "better?"
Better interface. Almost every user I met complained about the IE7 interface. It makes terrible use of space, while the FF interface uses the standard File/Edit/View bar, and the tabs area goes all of the way across which provides more room for tab labels. FF also crashes less. It also takes less time to display webpages. And if you show the average user what can be done with extensions they find interesting, they are totally sold on FF (I had one user switch just for the Colorful Tabs add-on).
I had an experience nearly identical to this in London when a shop clerk asking if we had a card with a chip in it to use. The friend I was with didn't even know what he was talking about. I explained things to her, and then told the clerk we didn't, but could wander off and find an ATM to use instead. He dug around some and found a card reader, but it was obvious he hadn't used it in a while.
... a convenient container for packaging multiple audio signals, subtitles and x264 encoded video and being all FOSS. its also a very popular format for anime, due mostly to its multiple audio and subtitle strengths.
the piracy scene decided on x264 mkv for various reasons but wide compatibility probably wasnt one of them...
A number of fansubbers interacted heavily with the Matroska development team during Matroska's development. Many streams was a given due to the inherent design, but the extra interaction ensured a good, simple, and elegant subtitle design. Subtitles are just another packetized stream, with times and durations handled completely by the container. There is also a heavy focus on complete flexibility in which codecs can be played together. (If you can get it into Matroska, you can play it with any other codec.)
AVI supports multiple streams *with severe limitations*. MPEG-TS/PS didn't carry anything other than MPEG formats, and was even worse than AVI for most circumstances. MP4 is the first industry container with proper support for more advanced features, though it has a heavy feature slant towards broadcaster design.
It *doesn't care* about the underlying codec's. For cripes sake, it supports DTS-HD out of the box without any special extensions.
It sure as hell does care. Read http://haali.net/mkv/codecs.pdf which goes into very specific detail on how to work with the "underlying codecs".
You notice that most of that is just saying "the codec initialization data is placed in the CodecPrivate element? The rest is details on this as prior to Matroska, codec developers would just place initialization information wherever.
In this respect, Matroska dramatically simplifies how codecs are used. My favorite is text subtitles, which are just timecoded Matroska data packets with the text to be displayed on the screen. The Matroska packet has the timecode the packet should be used at (when the subtitle appears on the screen), and the length of time the packet should be be used for (how long the subtitle stays on the screen for). Using another subtitle format, the exact same packet timecodes are used, with only the data for what displays on the screen changing.
It's taken a while for developers to get used to the idea that stream information be kept at the container level instead of being hidden inside of the codec, but once they saw it, they never wanted to go back. Many codecs prior to Matroska would store timing and packetization information in their own proprietary method/container. Now codec and software developers can completely ignore that part of development and just work on improving the data compression/decompression.
From the linked list, I see RealVideo, Theora/Vorbis, AC3, DTS, WAV, TTA Audio, WavPack, FLAC, SRT/Text, SSA/ASS, VOBSUB, and numerous MPEG containers. That's probably at least 15 different commonly used completely incompatible "containers". Now, a developer just needs to send data to and from a Matroska library and they can read/write any of those formats into the same file. Prior to Matroska there was ABSOLUTELY NO WAY to get some of these codecs to work with each other.
Just because you don't see the benefits doesn't mean they aren't there, and aren't a huge deal for developers and users.
Matroska also supports an unlimited number of tracks. That's pretty neat, though I don't know if anyone's doing much with that.
As I noted in another post, it even allows for variable frame-rate (VFR) encodings, meaning that the frame-rate can change in the middle of the video stream. This addresses a common problem with encoding DVD rips from sources with mixed content.
These are the two big points. Matroska stores packets with timecodes instead of using a packet sequence number tied to a frame rate. This means that you can vary your frame rates, or have gaps of arbitrary size between frames. This makes it particularly easy to join video where the ending of the first video's audio and video don't end in the same exact spot (something nearly impossible to do with AVI with re-encoding).
Most containers use a frame rate system, which makes variable frame rate codecs impossible to use. For instance, Vorbis is variable frame rate because packets cover a different amount of time. That is why it is impossible to place Vorbis in many containers.
And because you can interleave packets from however many different streams, it's trivial to use however many video, audio, and subtitle streams playing simultaneously from a single video file.
Of course, this is also its biggest hindrance. Video editing software is all designed around the idea of a constant frame rate, which Matroska has no sense of. Video editors and broadcasters are a different breed from computer people, and are stuck with the idea that video and audio be a constant frame rate at a constant bit rate. I remember the discussions for the (I believe it was the Chinese HD DVD format they were working on) where Vorbis was proposed. They wanted a constant bitrate audio format, and the Xiph folks told them Vorbis was a variable bit rate format, but it could have a ceiling for how high the bit rate got. This apparently wasn't good enough, and the Xiph folks had to tell them they could pad the Vorbis stream to make it constant bit rate.
There is a difference between "accidental damage" and "criminal intent". Intentionally committing a criminal act where one of the byproducts is failure of critical infrastructure could certain be labeled "sabotage".
Did I mention not being able to find the network panel? I'm pretty sure I didn't.
I mentioned that I've encountered many issues, and then offer details to two major usability issues (users being unable to deal with wireless networks, and some settings being literally impossible to find in the user interface without third party direction).
I then offer details to a show stopping bug. There are others, but I didn't feel the need to detail every bug I've come across, just to state that there are several serious bugs that haven't been resolved.
Please read more carefully in the future before trying to mock others.
but then, upon further research, i found out about dynamic textarea resizing, a useful little feature for lots of data entry, while using chrome. you just click and drag the corner of the textarea to make it bigger (or smaller). very nifty
Firefox has supported this for years through extensions. Probably the best known one right now is Resizeable Textarea.
Also, I would be cautious of recommending your Windows users to Safari. For some reason all Apple software in Windows seems to run exceptionally slow. I never realized what all of the hubub for Apple software was about until I tried it on a Mac. I don't know what they do to make it cross platform, but there are serious performance issues on the Windows side.
They state specifically that the controller arranges data for typical data access patterns, and that synthetic benchmarks writing randomly all over the drive screw with the optimizations they've done. I'd like to see tests done with real server software to see if the performance degrades significantly.
Flushing to disk imho can not work so well when the box is loaded with more IOPS than the spindles can handle.
Most high IOPS systems are high because of a high number of random reads. The spinning disk would only need linear writes, which should be pretty easy to sustain maximum transfer rates. That Tera-RamSan appears to use 128GB modules, so each would include its only spinning backup disk. Modern disks can easily sustain 100MB/s. A full dump would take 20 minutes.
I suspect they would at least implement a basic paging system where the RAM would have a 1:1 mapping on the harddrive. Then using block sizes (100MB or 10MB maybe) mark whenever a block has had data changed and is no longer current. Then take the changed block that has not been modified for the longest time and dump it to disk. Even for most large databases most data is written onto the end (or log files) so there are typically large contiguous sections that aren't written to often. And note that doing a mem copy for 100MB and then writing to disk is not going to be a blocking action.
It's possible that (depending on the load) a shutdown initiated flush of changed blocks wouldn't take very long. And more efficient algorithms could really strip that down.
Most of the JMicron controlled SSDs can not have their firmware updated. But I believe the controller chip itself is rather broken, so there is little a firmware update could do anyway.
I believe it's from Webster's 2nd or 3rd Unabridged.
I just checked their online unabridged version and it doesn't come up. (I pay for a subscription.) Perhaps someone could check Oxford's to see if it is there?
The word you've entered isn't in the Unabridged Dictionary. Click on a spelling suggestion below or try again using the search box at the top of this page.
And it wasn't that long ago that NTFS couldn't be used on a volume larger than 4GB.... then 32GB
I think you're confusing NTFS and FAT. On some older Microsoft OSs the installer would not allow you to install the OS on an NTFS partition larger than 4GB. You could create/format larger NTFS partitions, and even restore an OS image to a larger partition, but the installer didn't support it. I've never seen a report that the MS implementation of NTFS was ever limited to something as small as 32GB.
FAT12 is limited to 32MB, FAT16 to 4GB (though most implementations only support 2GB), and FAT32 to 2-8TB (though implementations vary support from as little as 32GB).
I think the last missing link in OOo's suite of tools is an answer to MS Office's SharePoint server.
Or, you know, that thing called "Outlook". Outlook/Exchange and its integration with the rest of the Office suite is the main reason that most companies still use Microsoft Office. There just isn't a reasonable alternative for it out there.
I wonder - how difficult is it to take a driver written for Linux and write one for Windows using the information it provides?
My guess would be "very difficult". I'm not sure what exactly would change, but given the lack of driver porting from Linux to Windows, there must be something. I've also noticed that for companies doing driver releases for a product in Linux and Windows, the version numbers are typically not the same and the release dates are never close. So I don't know why it would be hard, but I'm pretty sure it is.
Do we really need people who know how things work 'under the hood' to make smart tech decisions?
No, but someone with basic problem solving skills would be a good start. If you can't do something as basic as programming the clock on your VCR, how can I trust you to identify obvious BS while making federal decisions? And how could I trust you to identify the people you should surround yourself with to keep yourself informed?
I am afraid that you still not see my point: there is nothing you can do with a registry that you cannot do with a filesystem and config files.
Except look at an entry and immediately know the data type, and be able to make quick changes using that knowledge. Even from the command line. And for any program.
In Windows 95 the Windows Registry was pretty dodgy. From Windows 2000 on, it's been pretty solid. Most people against the registry are against it for outdated reasons, experience with poorly designed programs, or just a misunderstanding of how it works. As someone that has to make changes in both.conf files and the registry, I'd take the registry any day.
There is a specific syntax for reading/adding/removing information from the registry. An API if you will. And I suppose you could say that there are specific storage conventions, and all programs using the registry will be using the same conventions. Programs using.conf files will be using whatever conventions the authors of that specific program decide to use due to the position of the moon, and if they hear a dog howl that night. Sure, you can write binary data to the registry, but you can use poor programming techniques for anything. The point is that it is all standardized, easily accessible, and all in one place.
A filesystem however is standard and allows one to copy single files. This has as added advantage that an application can be copied to another computer, settings and all included.
There are few programs, in Linux or Windows, that can be moved to a different computer by copying a single directory. In both cases, the configuration must be hunted down. In a properly designed program using the Registry, you will only need to export the registry keys in the manufacturer's name (excluding Classes, which I already commented are screwed). Keys can be easily exported and imported from the command line or through scripts.
A million different keys spread out throughout the registry, each with it's own peculiar syntax.
As I mentioned before, all of the relevant keys should be located under the manufacturer's name in HKLM\Software\Manufacturer and HKCU\Software\Manufacturer. Not exactly complicated, but doesn't include poorly designed programs. And in the registry, if I have a piece of string data with a label, everyone knows exactly how it is stored and retrieved. With a.conf file it might use any number of possible random syntaxs. Having a script change a.conf file required knowing which file belongs to the program, where in the file the data is allowed to go, and configuring how exactly that data is labeled and stored. There are all far less of an issue with a hierarchy designed registry and strict syntax rules.
The Windows registry has two primary drawbacks. 1. It requires the use of a registry reader, which Microsoft makes, so it's limited to editing from Microsoft systems. 2. If the couple of registry files get corrupted, all of the data in them can be lost without recovery options.
People really need to get off their high horse and get over the fact that randomly designed and scattered.conf files are just somehow just so much better than a single hierarchy designed storage database with strict syntax, specifically designed for settings.
Unfortunately, in practice, it's a mess. Though, I really don't think the fault is entirely MS's. As you stated, too many developers simply dumped stuff in HKLM.
Actually, much of it is Microsoft's fault, and system wide settings are supposed to go into HKLM. Everything under HKEY\Software\Microsoft suffers from almost no organization. It's no wonder that other vendors were initially confused about how to organize their information. And then HKEY\Software\Classes is just plain scary.
Slashdot Mirror
If both FF and IE display the webpages they want, and the user don't care about anything else... in what way is FF "better?"
Better interface. Almost every user I met complained about the IE7 interface. It makes terrible use of space, while the FF interface uses the standard File/Edit/View bar, and the tabs area goes all of the way across which provides more room for tab labels. FF also crashes less. It also takes less time to display webpages. And if you show the average user what can be done with extensions they find interesting, they are totally sold on FF (I had one user switch just for the Colorful Tabs add-on).
I had an experience nearly identical to this in London when a shop clerk asking if we had a card with a chip in it to use. The friend I was with didn't even know what he was talking about. I explained things to her, and then told the clerk we didn't, but could wander off and find an ATM to use instead. He dug around some and found a card reader, but it was obvious he hadn't used it in a while.
Google has never given me an expensive speeding ticket under suspicious circumstances.
... a convenient container for packaging multiple audio signals, subtitles and x264 encoded video and being all FOSS. its also a very popular format for anime, due mostly to its multiple audio and subtitle strengths.
the piracy scene decided on x264 mkv for various reasons but wide compatibility probably wasnt one of them...
A number of fansubbers interacted heavily with the Matroska development team during Matroska's development. Many streams was a given due to the inherent design, but the extra interaction ensured a good, simple, and elegant subtitle design. Subtitles are just another packetized stream, with times and durations handled completely by the container. There is also a heavy focus on complete flexibility in which codecs can be played together. (If you can get it into Matroska, you can play it with any other codec.)
MKV is superior container because it allows multiple streams within a single container, including multiple languages and subtitles.
You mean like AVI, MPEG, and MP4 all do? http://www.alexander-noe.com/video/amg/en_myths.html
AVI supports multiple streams *with severe limitations*. MPEG-TS/PS didn't carry anything other than MPEG formats, and was even worse than AVI for most circumstances. MP4 is the first industry container with proper support for more advanced features, though it has a heavy feature slant towards broadcaster design.
It *doesn't care* about the underlying codec's. For cripes sake, it supports DTS-HD out of the box without any special extensions.
It sure as hell does care. Read http://haali.net/mkv/codecs.pdf which goes into very specific detail on how to work with the "underlying codecs".
You notice that most of that is just saying "the codec initialization data is placed in the CodecPrivate element? The rest is details on this as prior to Matroska, codec developers would just place initialization information wherever.
In this respect, Matroska dramatically simplifies how codecs are used. My favorite is text subtitles, which are just timecoded Matroska data packets with the text to be displayed on the screen. The Matroska packet has the timecode the packet should be used at (when the subtitle appears on the screen), and the length of time the packet should be be used for (how long the subtitle stays on the screen for). Using another subtitle format, the exact same packet timecodes are used, with only the data for what displays on the screen changing.
It's taken a while for developers to get used to the idea that stream information be kept at the container level instead of being hidden inside of the codec, but once they saw it, they never wanted to go back. Many codecs prior to Matroska would store timing and packetization information in their own proprietary method/container. Now codec and software developers can completely ignore that part of development and just work on improving the data compression/decompression.
From the linked list, I see RealVideo, Theora/Vorbis, AC3, DTS, WAV, TTA Audio, WavPack, FLAC, SRT/Text, SSA/ASS, VOBSUB, and numerous MPEG containers. That's probably at least 15 different commonly used completely incompatible "containers". Now, a developer just needs to send data to and from a Matroska library and they can read/write any of those formats into the same file. Prior to Matroska there was ABSOLUTELY NO WAY to get some of these codecs to work with each other.
Just because you don't see the benefits doesn't mean they aren't there, and aren't a huge deal for developers and users.
These are the two big points. Matroska stores packets with timecodes instead of using a packet sequence number tied to a frame rate. This means that you can vary your frame rates, or have gaps of arbitrary size between frames. This makes it particularly easy to join video where the ending of the first video's audio and video don't end in the same exact spot (something nearly impossible to do with AVI with re-encoding).
Most containers use a frame rate system, which makes variable frame rate codecs impossible to use. For instance, Vorbis is variable frame rate because packets cover a different amount of time. That is why it is impossible to place Vorbis in many containers.
And because you can interleave packets from however many different streams, it's trivial to use however many video, audio, and subtitle streams playing simultaneously from a single video file.
Of course, this is also its biggest hindrance. Video editing software is all designed around the idea of a constant frame rate, which Matroska has no sense of. Video editors and broadcasters are a different breed from computer people, and are stuck with the idea that video and audio be a constant frame rate at a constant bit rate. I remember the discussions for the (I believe it was the Chinese HD DVD format they were working on) where Vorbis was proposed. They wanted a constant bitrate audio format, and the Xiph folks told them Vorbis was a variable bit rate format, but it could have a ceiling for how high the bit rate got. This apparently wasn't good enough, and the Xiph folks had to tell them they could pad the Vorbis stream to make it constant bit rate.
There is a difference between "accidental damage" and "criminal intent". Intentionally committing a criminal act where one of the byproducts is failure of critical infrastructure could certain be labeled "sabotage".
Did I mention not being able to find the network panel? I'm pretty sure I didn't.
I mentioned that I've encountered many issues, and then offer details to two major usability issues (users being unable to deal with wireless networks, and some settings being literally impossible to find in the user interface without third party direction).
I then offer details to a show stopping bug. There are others, but I didn't feel the need to detail every bug I've come across, just to state that there are several serious bugs that haven't been resolved.
Please read more carefully in the future before trying to mock others.
The show stopping bugs I mentioned a year ago are still in Vista, even after SP1. I never experienced similar issues with 2000 or XP.
Firefox has supported this for years through extensions. Probably the best known one right now is Resizeable Textarea.
Also, I would be cautious of recommending your Windows users to Safari. For some reason all Apple software in Windows seems to run exceptionally slow. I never realized what all of the hubub for Apple software was about until I tried it on a Mac. I don't know what they do to make it cross platform, but there are serious performance issues on the Windows side.
They state specifically that the controller arranges data for typical data access patterns, and that synthetic benchmarks writing randomly all over the drive screw with the optimizations they've done. I'd like to see tests done with real server software to see if the performance degrades significantly.
Most high IOPS systems are high because of a high number of random reads. The spinning disk would only need linear writes, which should be pretty easy to sustain maximum transfer rates. That Tera-RamSan appears to use 128GB modules, so each would include its only spinning backup disk. Modern disks can easily sustain 100MB/s. A full dump would take 20 minutes.
I suspect they would at least implement a basic paging system where the RAM would have a 1:1 mapping on the harddrive. Then using block sizes (100MB or 10MB maybe) mark whenever a block has had data changed and is no longer current. Then take the changed block that has not been modified for the longest time and dump it to disk. Even for most large databases most data is written onto the end (or log files) so there are typically large contiguous sections that aren't written to often. And note that doing a mem copy for 100MB and then writing to disk is not going to be a blocking action.
It's possible that (depending on the load) a shutdown initiated flush of changed blocks wouldn't take very long. And more efficient algorithms could really strip that down.
Most of the JMicron controlled SSDs can not have their firmware updated. But I believe the controller chip itself is rather broken, so there is little a firmware update could do anyway.
I just checked their online unabridged version and it doesn't come up. (I pay for a subscription.) Perhaps someone could check Oxford's to see if it is there?
Who?
I think you're confusing NTFS and FAT. On some older Microsoft OSs the installer would not allow you to install the OS on an NTFS partition larger than 4GB. You could create/format larger NTFS partitions, and even restore an OS image to a larger partition, but the installer didn't support it. I've never seen a report that the MS implementation of NTFS was ever limited to something as small as 32GB.
FAT12 is limited to 32MB, FAT16 to 4GB (though most implementations only support 2GB), and FAT32 to 2-8TB (though implementations vary support from as little as 32GB).
Or, you know, that thing called "Outlook". Outlook/Exchange and its integration with the rest of the Office suite is the main reason that most companies still use Microsoft Office. There just isn't a reasonable alternative for it out there.
My guess would be "very difficult". I'm not sure what exactly would change, but given the lack of driver porting from Linux to Windows, there must be something. I've also noticed that for companies doing driver releases for a product in Linux and Windows, the version numbers are typically not the same and the release dates are never close. So I don't know why it would be hard, but I'm pretty sure it is.
No, but someone with basic problem solving skills would be a good start. If you can't do something as basic as programming the clock on your VCR, how can I trust you to identify obvious BS while making federal decisions? And how could I trust you to identify the people you should surround yourself with to keep yourself informed?
There is a good joke in there somewhere.
Except look at an entry and immediately know the data type, and be able to make quick changes using that knowledge. Even from the command line. And for any program.
In Windows 95 the Windows Registry was pretty dodgy. From Windows 2000 on, it's been pretty solid. Most people against the registry are against it for outdated reasons, experience with poorly designed programs, or just a misunderstanding of how it works. As someone that has to make changes in both .conf files and the registry, I'd take the registry any day.
There is a specific syntax for reading/adding/removing information from the registry. An API if you will. And I suppose you could say that there are specific storage conventions, and all programs using the registry will be using the same conventions. Programs using .conf files will be using whatever conventions the authors of that specific program decide to use due to the position of the moon, and if they hear a dog howl that night. Sure, you can write binary data to the registry, but you can use poor programming techniques for anything. The point is that it is all standardized, easily accessible, and all in one place.
There are few programs, in Linux or Windows, that can be moved to a different computer by copying a single directory. In both cases, the configuration must be hunted down. In a properly designed program using the Registry, you will only need to export the registry keys in the manufacturer's name (excluding Classes, which I already commented are screwed). Keys can be easily exported and imported from the command line or through scripts.
As I mentioned before, all of the relevant keys should be located under the manufacturer's name in HKLM\Software\Manufacturer and HKCU\Software\Manufacturer. Not exactly complicated, but doesn't include poorly designed programs. And in the registry, if I have a piece of string data with a label, everyone knows exactly how it is stored and retrieved. With a .conf file it might use any number of possible random syntaxs. Having a script change a .conf file required knowing which file belongs to the program, where in the file the data is allowed to go, and configuring how exactly that data is labeled and stored. There are all far less of an issue with a hierarchy designed registry and strict syntax rules.
The Windows registry has two primary drawbacks. 1. It requires the use of a registry reader, which Microsoft makes, so it's limited to editing from Microsoft systems. 2. If the couple of registry files get corrupted, all of the data in them can be lost without recovery options.
People really need to get off their high horse and get over the fact that randomly designed and scattered .conf files are just somehow just so much better than a single hierarchy designed storage database with strict syntax, specifically designed for settings.
Actually, much of it is Microsoft's fault, and system wide settings are supposed to go into HKLM. Everything under HKEY\Software\Microsoft suffers from almost no organization. It's no wonder that other vendors were initially confused about how to organize their information. And then HKEY\Software\Classes is just plain scary.
A thousand .conf files spread out throughout the directory structure, each with it's own peculiar syntax. Oh yeah, that worked real well.
The Windows registry might not be great, but it's better than the alternative.