Slashdot Mirror

Amen. An older example is PS/2 peripherals. If it weren't for Microsoft's Windows Logo requirements, every desktop would have two PS/2 ports. Even my 2007 Pentium 4 has them.

I'm going to complain about the removal of the floppy drive too. Flash drives are expensive, and CDs are both expensive and a PITA. But floppy disks are cheap and easy to use, making them great for turning in homework, distributing software, etc.

I find it hilarious that we aren't over those size limits yet. :-D

A history lesson here:
http://www.dewassoc.com/kbase/hard_drives/hard_drive_size_barriers.htm

Those are "logical" sectors, which can be different from the physical sector size. [...] ...logical sector size is a drive interface level concept distinct from the filesystem cluster or block size. Filesystem block sizes have generally been larger than the logical or physical sector size for quite some time.

Thank you, butlerm for some much needed sanity in this thread.

The notion of cylinder/head/sector in the literal sense has been completely deprecated, but the scheme was preserved as an ad-hoc standard... which has since run into five other "hard limits" in BIOS and Int0x13 addressing... but that's another story.

Around the time of the first BIOS addressable-space limitation of 528MB, most hard disks were already being mapped with ZBR and translated through firmware. (see Zoned Bit Recording) The standard of 512b/sector has simply been a case of tradition and best practice. It was "just they way they made them."

A new logical int0x13 hook driver is all that's needed to interpret C/H/S coordinates with a 4KB base instead of a 512B base, and M$/Apple/Linus (et al) can likely cook that up in their sleep. No applications—short of low-level virus scanning, low-level disk utilities and software RAID, to name a few—would be affected by a different "physical" sector size. Most apps are in "virtual mode" and treat files as objects, which is handled in turn by the core OS.

Most filesystems use 4K granularity as it is, all that needs to happen is to equate cluster with sector. (as a most simplified "patch") I'm sure they'll come up with a new scheme to keep it scaled up... such as 4 sectors per cluster. (becoming 16K cluster/block size)

The greatest headache will be the game of catch-up by the OS-dev and utilities arena, who now have to completely review their preconceptions about HDD storage. Think regression-testing-cubed.

While we're at it, let's correct TFP by saying that filesystems will always align partitions to the beginning of the next logical cylinder. (whether it's a multiple of 4KB or not) The most likely problem to arise would be with the utilities mis-reading the "Advanced Format" disks, (showing them at only 1/8 of their actual size) calculating capacity based on total-sectors*512b, instead of the correct formula of total-sectors*4096b.

If you think about it, it's really a practical step. Think of where HDD sizes were ten years ago; 40GB was gi-normous and 100GB was just a pipe-dream. Ten years before that? A 100MB disk was "spacious" ...just a 1GB disk wouldn't be available for another five years. In all that time, the sector size hasn't changed at all... just half a kilobyte. It's a sign of the times, people.

Think of it this way... now instead of the nerdy term "sectors," you can introduce a newer term like "quads" or "kilo-quads" and see if it catches on.

There may be limitations in what can be concatenated.

We were talking about Javascript. There shouldn't be any problem concatenating multiple script files together into a single script file. (And, for that matter, running it through a minifier and serving it via gzip.)

For example, textures used as CSS sprites can't be scaled.

Granted -- or at least, not easily. I believe you can render HTML to a Canvas element -- thus, if you can render it, you can scale it.

But what does this have to do with concatenating Javascript files?

Have you any evidence that Internet Explorer does "know how to make multiple requests at once"?

In its default configuration, I believe it still defaults to 2 at once for HTTP 1.1, and 4 for HTTP 1.0. And this can be adjusted. Source.

the bugs are in the translation of the spec from English to code in the tests, just as they would be in the translation of the spec from English to code in the actual product.

You really don't see how it could possibly be easier to code a test that matches a spec, versus an actual product that matches a spec? I mean, we agree that tests and formal specs both define what, not how? And the actual product must necessarily define how?

For that matter, have you seen rspec? It's possible to go pretty much directly from user stories (management-readable specs) to executable code.

Anecdotally, I can say that I've very, very rarely had more bugs in the tests than I do in actual code, and I can't ever remember a bug in the test that was silently ignored -- bugs in my tests lead to test failures. The only way a bug silently sneaks into production, where I need robust debugging tools, is where I didn't test something, not where I tested something incorrectly.

I do appreciate a decent debugger, but if I had to choose, I'd choose a robust test suite over a debugger any day.

Nobody I know in Fort Wayne, Indiana, a city of 200,000 people, has over 50 Mbps Internet to the home.

Which is still close to that, and fast enough to stream a DVD.

Oh, and I've got 100 mbit Internet, at a reasonable price, in Fairfield, Iowa, a city of 10,000 people.

Point is that even a tenth of that is easily sufficient.

Where an enemy pops up and kills the player's character before the enemy's texture finishes downloading.

Ah, interesting. Also can't remember ever actually seeing that.

It's also strange that you'd have this, yet not have similar things happening in the environment -- especially as I remember this being talked about in relation to the environment, not the enemies.

so yes, I expect Vista to run in classic windows mode on a 1ghz AMD w/ a GForce 5600 graphics card. It won't be blazing fast, but it should run basic apps (office/web browser/email) with out a problem.

That's nice. But you said that W2k users shouldn't have to upgrade their hardware to run Vista in classic mode. But Windows 2000 required only 64 meg ram (according to http://www.dewassoc.com/support/win2000/require.ht m), not 512 meg, like you just quoted for Vista.

Now, I'm sure that most W2k users have more than 64 meg. Some might even have 512 meg. But nonetheless, it's misleading to say that W2k users won't need to upgrade. Those of us that don't upgrade very often are likely to have machines that run dog-slow for Vista or not at all.

I thought the first partition, being closer to the inside of the platter, had shorter seek times. This means that the arm would move less hence less wear and tear. Also means faster to access information than that stored on the outside of the platter hence better performance. Can you point out the site that proves this to be urban myth? Phillip.

You should really read the article before thinking you understand the commentary on it. Let me help you out. The statement was:

You should always have a dedicated partition for your temp files and swap file. It's tempting to actually put this on a separate physical drive to reduce the wear and tear on the main drive, but the disadvantage is that upgrading to a larger hard drive a more involved process.

Note that it says "dedicated partition", not "first partition".

The outer sectors are the faster ones, not the inner ones, although your assumption about that being where the first partition ends up does hold true. Here's a good explaination of why: http://www.dewassoc.com/kbase/hard_drives/hard_dis k_sector_structures.htm

If one were actually to go to the trouble of installing XP with the intention of using the first partition as swap, and second etc for OS and data, there would be some validity to the idea. However, you'd be putting your OS and data deliberately on slower parts of the disk, to speed up the swapfile which you don't want to ever use anyway (if you can help it).

Just trust me, if you're performance tunig your swapfile, you're putting your efforts into the wrong bucket. You need more ram.

I'm not sure why you were modded down, apart from your MTBF numbers for IDE being a bit odd. Still, that is another good point. Here's a page that really covers the SCSI vs IDE debate well:

http://www.dewassoc.com/kbase/hard_drives/scsi_vs_ ide.htm For anyone considering using IDE for performance or redundancy, this should really put it in perspective.

umh,
award is phoenix, they merged back in 1998 http://www.dewassoc.com/support/bios/awardfaq.htm# Q2.2
go to www.award.com and you will be directed to phoenix.com.