GNU has done very little for application developers. No GNU platform is a viable platform for shipping consumer-level applications on, yet...
I'm sorry, then what exactly is on your Mac? On every new solaris system? On every Linux machine?
When I say developers, I don't mean people who toil away. I mean people who make a business of it.
Yeah see, that's why you're a dick. You immediately mean to say that what I do, isn't business. If it always shows a profit, and it pays people their sole income to put food on the table for more than a dozen people, it's not a business because it's based on GNU.
Fuck you.
Windows is not pleasant to develop for. But the money makes it worth it.
Obviously to you. But as I kindly point out, you're nothing but shit for brains with confused half-concepts of what business is, what makes you think that you can tell me what is worth it?
New developers don't know better. Kids that come out of school simply do not know what it is like to develop on an enjoyable platform.
And it doesn't matter where half the money of that low-cost systems goes to.
Again, shit for brains.
That system would never have reached $500 with just Apple making GUI systems.
You're completely confused. I happen to have on my desk right now, a $500 modern macintosh. It's actually worth it. At the other end of my desk, a $250 Linux workstation. It's worth it too.
My neighbor has a $500 DELL. It's not worth it, not even to them. To the point where it gathers dust, and my machines get used every day.
It took the competition of Windows to make that happen.
Until you pass Go and collect a clue, don't ever suggest for a moment that Windows has ever competed with anyone. They are sub-par products by sub-par people that charge an arm and a leg (not to mix metaphores: creating more sub-par people) because of an illegal monopoly.
Tell me, kind wizard: If nobody enjoys developing on it, and nobody enjoys using it, how can ``The Money'' it possibly be worth it to anyone to write on it?
Because they're an illegal monopoly it's everywhere. Everywhere can make it worth it to some people to write for it. Being as how that everywhere is getting smaller every day, I find it easier to convince people that it isn't.
But I'm so glad it's 1998 again, and retarded monkeys like yourself can post to slashdot and remind us that you're only doing software development for real, when you do it on Windows.
As a side note, it's interesting that you point out by your own convictions that you don't do software development for real, and then intend to lecture those who by their own definitions, do.
Anyone who watched the PC platform when Windows 95 came out knows better than to say that MS stifled development.
Agreed. I think it's more appropriate to say they set it back twenty years.
By creating a platform for developers,
Actually, that was GNU: By developers and for developers. Windows is probably the most unpleseant platform to develop for still in active use.
they allowed the lowly PC platform to catch up greatly to the Mac in usability
You'll end up shot if you tell a Mac person that.
Windows never came close to MacOS in terms of usability. Not to mention your leading about developers- MacOS was and still is extremely pleseant to develop for.
and bring capabilities to buyers of low-cost hardware that might never have come to them otherwise.
There is no reason why you can't migrate 99.999% of all servers to TCPv2 and not notice a difference.
Sure there is, it's the exact same reason you cannot migrate servers to IPv6. There isn't a migration plan.
ALL software that stores IP addresses or port numbers needs to be updated to the new "format". That's what a lot of people think is the big hurdle, but it's not. It has to be done with no new "knowledge" of each piece of software.
New services are what is quoted as being the big push for new address spaces. HTTPS should've used SRV, and has a built-in time limit (whenever the new root certificates expire). HTTP should've used SRV, but no such time limit exists.
How do you upgrade clients to a system without servers, and how do you upgrade servers to a system without clients?
The only answer the IPV6 working groups can come up with is "get everyone on both until everyone's on both."
That's not a migration plan. That's billions of dollars of work for no real gain. Not when "most people" can get things like address compression a lot faster and still interoperate on both sides of the fence (albeit: with some possible workarounds for really ancient clients).
So the million dollar question is why migrate thousands of protocols and thousands of platforms for address spaces that no one has a use for, when we can migrate dozens of protocols, and plan for future ones with no change at all to most existing clients or servers, and very little change to a few.
I'm sure there are quite a few- and they should be reallocated.
Nobody will switch to IPV6 because there isn't a migration plan- there aren't proxies, there aren't anything.
IPV6 doesn't deserve to be called "Internet2" because nobody uses it. Not for Internet access.
I have no idea why methods of address compression aren't being used- like using SRV records so that we can use the additional 16-bits of ports as addressable space.
I count 524,544 ip addresses right there. It's pretty amazing because cisco only has 34,000 employees, or 15 IP addresses per person.
No wonder they don't want to give any addresses back. It's a lot of work to use public addresses effectively.
Meanwhile, convince everyone else to spend umpteen-trillion dollars to switch to IPv6 or only the people who want to get on the Internet in the next few years, and they don't have to do a damn thing.
Oh, and I'm almost certain cisco has other netblocks. Those are only the ones I know of off the top of my head.
You simply can't expect joe public to ever learn how to compile his kernel and even messing around with kernel modules is probably asking too much.
That's a good point! Why exactly does ATI make you compile your kernel on Linux but not under Windows? What is wrong with them?
I think it's just amazing that some people can get unsupported hardware to work under Linux (you included!).
I've got some TV cards on the other hand, that don't have drivers past Win98, and simply won't work in Windows at all.... in fact, almost all my hardware "just works" with Linux. I guess that's what I get for buying supported hardware.
So from where I'm standing, Linux has excellent driver support. It's ATI that's a piece of shit.
Take a (non-existant) Unix only user and give them Windows. They have the same issues. Take someone fluent in spanish and transport them to India. Same problems.
Speaking as a unix-only user, I cannot use windows. It's worse because many of the Windows users have no problems using Unix around my office, but myself (and the other unix-only folk) are completely lost when it comes to Windows.
Think of this without bias. If you had been thrown into Windows XP for the first time and asked to do the same thing, would you know that Outlook is a frigging e-mail program!!!??? Its icon doesn't even have anything to DO with e-mail. Changing a date - woo-hoo! Right-click the date. Thank GOD they got that right!
In fairness: Outlook Express is what many people call Outlook. It's icon is appropriate. Users have had to explicitly install Outlook to get it- and during installation, it's made very clear what Outlook is.
UI design is flailing in the OSS community because the resources M$ throws at UI design don't exist - especially in the FOSS subset of the OSSers. Do you have millions of dollars to do user usability testing - as in the people who wouldn't volunteer freely to "beta" something - the ones that outnumber the beta testers 50 to 1. Do you have millions of dollars for focus groups and other UI related tasks?
This is confusing. You're blurring the distinction between approachability and usability. Many (most?) unix programs have far more usable and productive user interfaces than their Windows counterparts simply because when they're used, they're used a lot. Asking a programmer to do a repetitive task simply because it's easier for someone who isn't is just foolish. Programmers scratch those itches so that after thirty-years or so, they are simply so rare it's not even funny.
Now approachability is a different issue. UNIX is certainly less approachable than Windows- except perhaps in recent years. I have noticed that ten years ago, many neophites were afraid to go up and touch a unix workstation (perhaps it's because people in suspenders are scary), but nowadays, such fears are almost completely gone.
The biggest problem with approachability is that it not surprise the user- getting an error about some "Illegal Operation" one purportedly performed is a great way to scare the user- they might not come back, and because they were still in the approaching-productive phase, this hurt approachability.
Novell is targetting people that aren't in the approaching-productive phase. These people already know how to perform tasks in their domain. The goal here is to improve approachability without damaging usability- something that UNIX desktops are already way ahead of their Windows counterparts- something that would happen immediately by "copying" menus and what have you.
The difference is money. Give the same efforts that M$ puts into UI usability and testing to the FOSS folks and you'd have - well a better Windows, but definitely a much better UI.
Microsoft doesn't put the kind of money into usability testing that people think. They haven't until very recently, and overall, surprise-surprise! UNIX people are spending (collectively) more than Microsoft. Every shop that "switches" to Linux spent money and time doing usability testing- Every programmer that develops for POSIX- Every CGI- Almost every time someone is using these "new things" it's being tested.
The trick is that Microsoft already has a monopoly. People rarely test the usability of Windows- but when they do, they find it often loses! For real work, it simply cannot compare.
You forgot the Archimedes O/S, which was the first one to have a task bar, as far as I know.
I most certainly did not! I have fond memories of RISC/OS, I simply don't believe that thing qualifies as a task bar as it operates more like the dock on NeXT. (which is different than it's "task bar").
The Amiga also had a nice mechanism for associating files with programs, as well as a local registry inside the application directory for each executable, meaning that apps did not have to be installed, just copied (and they could be moved after installation).
Agreed. The Amiga clearly did this right, but while it beats Windows by years, MacOS still beat Amiga.
Maybe your GNOME does, but not mine. People have developed an awful lot of muscle memory using that task bar, and GNOME is by-and-large, an excellent migration tool: my GNOME doesn't have a task bar at all.
KDE has something very similar.
KDE doesn't adopt things for being "a good user interface" and doesn't reject things for that reason either. This is probably why KDE development is so fast. FWIW, the KDE task bar (like the GNOME one), although able to make migration easier, is NOT anywhere near as bad as Windows.
OSX has something similar.
No. This is completely and totally rejected. OSX doesn't have a task bar, it has a dock, which in many ways does the things that a task bar can do right, but doesn't do ANY of them wrong. The dock doesn't work like the task bar (I can drag stuff to and from it and it does what I expect), dropping an item on a task (open or closed) has the appropiate effect
The OSX and NeXT dock is very similar- unless you use these systems. Saying the windows taskbar is like the NeXT dock is like saying the Windows command prompt is like a UNIX shell and terminal. It's not. Not even close. Not even remotely close. Not even mistakably close. Not even reasonably possible to mistake one for another.
No.
What DOESN'T have a taskbar of some description?
Besides MacOS/NeXT?
OSF/Motif, MacOS "classic", GEM, GEOS, Workbench (Amiga), just to name a few.
Note that what a taskbar makes is an omnipresent window list displaying each window as a separate element. If this window list is available on demand (instead of omnipresent), sortable, collapsable, or task-oriented (as opposed to window-grouped) then it's satisfactory.
Note that the GNOME and KDE "window list" knobs satisfy this. MacOS/NeXT is task-oritented and not a "window" (but instead an application) and not a window-list in the sense that that REALLY IS the application [as far as the user is concerned].
First, these are controllers, not disks. Second, they do indeed have a battery, as they well should -- it's used for their nonvolatile cache, which keeps your data nice and safe in RAM while the power goes out. It is absolutely not used to flush the cache by running the disks on battery. This is a PCI card, fer crying out loud. There isn't even a physical power cable between it and the disks you seem to think it's powering!
Battery-backed cache protects cached data in the event of a power outage, server failure or controller failure, and redundant batteries take that protection even further.
And by the way, when most of the controller hardware is physically on some disks and on an expansion card on others, blurring the distinction seems acceptable to me when we're talking about durable systems.
Simple - a journalling filesystem is designed to protect changes to the filesystem itself - not to it's contents. So in the case of a bad shutdown, it ensures that all the information about files and directories and which disk blocks belong to which files is consistent.
Absolutely not! Some journalling filesystems are designed to protect changes to metadata, but not all. Many consider protecting data to be prohibitively expensive, but that's not the same thing.
However, it makes no guarantees about the data contained within those disk block - if you've appended data to a file, the extra blocks will have been added to the file, but the actual data may not have been written to them.
I never append to files that I cannot live without. Rarely is it that I do it at all; my most common abuse of this is debugging logs that are easier to watch live. I also usually put them in/tmp.
1. The "taskbar". Before Windows 95 there was a concept of a window being "iconized", where the "icon" vanished if the window was open. It appears that Microsoft first made an "icon" that stayed there even if the window was open.
Err, both NeXT and OS/2 did this. Furthermore, there's a very good reason almost nobody else uses the "task bar": it's a terrible user interface.
2. Also in the taskbar, the realazation that words are more important than icons, and shrinking the icon to a more appropriate 16x16 size and making the text visible.
In OS/2, you got the entire text. Even for Modal Windows (which don't show up on the Win95 task bar). For NeXT you got a tool tip of the full text, and never an amended version (like you'll see in Win95).
3. Eliminating the artificial dividing line between the window border and the contents, so that a window displaying a uniform gray rectangle of the right color blends cleanly into the border. Although I wrote something like this myself quite a few years earlier for the NeXT, I hardly publicized it, and never saw similar graphics design until Windows.
Wow. Many MacOS and OS/2 applications did this exactly, and NeXT did it one better by getting rid of the window border itself.
4. "Combo box" where text input and multiple selection are done by the same widget. Having worked with NeXT before this, I'm pretty certain it did not have this, and never saw it on any other system either. (crappy popup implementation with the scroll bar is irrelevant to the innovation, although I really wish they would fix that...)
NeXT most certainly did have it, and so did Motif. They were uncommon with Motif, but SGI used them quite a bit.
5. Scroll wheel. The idea of having another control to scroll data on the mouse was older, but Microsoft seems to have realized that a 1-D version would provide most of the benifit without the confusion or flakiness of older attempts that tried for 2 or even more degrees of freedom.
Wrong again fanboy, both Kensington and Logitch did it with a knob, and Logitch even did it with an actual toothed wheel that was much easier to use than the Microsoft bastardization.
This is exactly why Microsoft has a patent on using a scrolling wheel as a z-index instead of as a scrolling device.
6. Having all files be "commands" in that if you double-click it examines the file (even if only the filename) and opens it with the correct program. The Mac does not count because it relied on imbedded metadata in the file, rather than an outside deciding program. Nor does #! notation in Unix exec of files, as it still requires the execute bit and does not work for files that lack this. I think a very important detail is that this idea could have been implemented 20 years earlier, it does not rely on GUI, and no CLI system ever did. A useful idea that is not realized until long after it is possible is a real indication that it is an "innovation".
First of all, MacOS doesn't work that way; the "type extension" is 4 characters (instead of three), but it's basically the same mechanism. Furthermore, multiple programs that support editing a file type are all accessible (as the creator is additionally available as another 4-character extension).
Why are these things invalid when they're clearly part of the file name?
So even if you refuse to let the Mac count for other reasons, why don't GEM, OS/2, OSF/Motif, CDE, or NeXT count?
Do do any other filesystems work like this because it seems like your post is specifically speaking of Ext3
All UNIX filesystems operate in the manner that I described. It's a requirement, and is often referred to as "UNIX semantics".
The -o data=journal part IS ext3 specific. Both ext3 and jfs are theoretically safe (on Linux. BSD's FFS should also be safe due to ordering). Reiserfs is NOT safe. XFS probably is, but the manuals should be checked.
I don't see why you would need a system shut down immediately.
I don't see why you wouldn't want a system that could shut down immediately. I mean, a TiVO should just eat all my shows if lightning strikes my house, right?
I find that weird stuff happens once you give a system to a customer that runs on a computer, and looks like a computer, but isn't a computer. These people don't know how to shut things down, and they become extremely irritated when you tell them that they have to do some kind of weird magic.
Especially after they've seen my demonstration and know that they don't:)
The [S]ATA spec allows the disk cache to be enabled or disabled by the user at any time. Disabling the cache cannot return "success" until there are no writes outstanding to the disk.
There exist IDE disks that ignore this setting.
... nor would any manufacturer be stupid enough to offer such a feature.
Compaq Smart Array 5300 family uses a battery to accomplish this very thing. They advertise it too.
Do you have any idea how long it would take to flush out even a megabyte of small random writes? You'd have to slap a battery on the disk, and a 12V battery at that. Or use NVRAM for the cache, which is what good RAID controllers do.
Why would you need a battery exactly? Many drives have such a small on-disk cache that a few capacitors have enough power to flush the cache.
Not atomic snapshots. Not that everyone needs this, but if you do, it does require FS support. Netapp's file system, for instance, supports atomic snapshots. Very nice for hot backups of DB data files, for example
You don't need the filesystem itself to be designed for it. If the filesystem supports an unmount operation, LVM could eventually do it. XFS's freeze operation is a good example of this.
Well, since Reiserfs doesn't do what you want, why not switch? Or consider adding the support you DO want to Reiserfs? Or pay someone to do it!
Also I do not like the idea of a user process directly accessing the FS. Probably good enough for a virtual machine environment where you can stop the machine and run the program, but this is for a live filesystem.
You're kidding, right?
What do you think fsck does?
For swap, it would be possible to zero it on boot and shutdown, but it takes a bit too long on my 2GB swap, and also it would not help against forensic analyzers who are careful not to boot the system.
What you really seem to want is an encrypted block device.
Exactly like a tape drive. Because of this, you get all the benefits of a type drive: straightforward implementation, guaranteed write times, and inherently transactional.
This is a good thing.
Correct me if I'm wrong, but I was told that ext2/ext3 would keep a file whole
You're wrong. Firstly, fragmentation isn't necessarily a bad thing. Generally collecting data as long as you're going the same direction (continuous sectors, or alternating) is very fast. Fragmentation is a very good thing in specialized systems where you need a guaranteed read time (as opposed to fast if possible, slow if not).
... The seek time is the same no matter how the file is sitting on the drive.
No it's not. On modern disks, switching heads is instantaneous because it's an electronic (not a mechanical) operation. Moving the head to the next physical sector is fast, but moving it "backwards" is slow (you have to do a full revolution). Extending to a different track is also slow.
Certainly, there is some aspect of the geometry that can make seeking faster.
It has something called 'snapshots', which seems to mean that you can work off of a partition, but seperately load up the version of that partition you had before you last had a power failure, or whatever went wrong.
Snapshots are easy to get without filesystem support (LVM).
* Minimal damage to file data and system consistency on hardware failure
Log-structured filesystems do NOT do this. For this you need RAID.
* Correctly ordered data and meta-data writes
Again, not inherent to a log-structured filesystem. In fact, every filesystem should have a correct way to perform ordered writes, and as long as recovery is done by a knowlegable system, most filesystems can be trivially converted to journalled filesystems.
* File and inode blocks are managed by a B-tree structure
Again, not inherent to a log-structured filesystem. Many filesystems use this method because it's easy, but note that B-trees (or B+Trees) aren't necessarily faster for real-world activity, and a poorly balanced tree can even provide much worse performance than a naive approach.
VMS has done this for years, and it IS great. But really, you should consider using one of these log structured filesystems (like what the article is about) because it already does exactly this.
I am probably not the only one to come back to an old file saved years ago only to find a glitch in it. I noticed it with a couple of movies. Movies I know were perfect as I watched them without copying them. So the only explanation is that part of the disk got corrupted.
That doesn't follow. Perhaps your filesystem isn't safe, or configured to be safe.
I've had a UFS system eat entire (old) directories due to the directory being updated and an untimely crash.
Ever since journaling file systems became available I just started turning the power off to my computers (via a power strip) rather than going through the shutdown command.
That's a very bad idea. Normally, journaling file systems only guarantee that the file/directory structure remains intact. It does not necessarily guarantee that the data in the files hit the disk.
Sure it does: mount -o sync,data=journal
Also, your disk will probably have a cache that is lost when you remove power. Whatever is in the cache will also be lost.
Hogwash. Disks that have such a cache have no command that tells them to actually flush their cache. They simply flush the cache whenever convenient or when power supply is lost to the disk.
So your file system may be intact, but your practices will probably destroy data.
That makes no sense. Either my files system is intact, or it isn't. I reject the notion that my file system can be intact but that data is destroyed.
What's more likely is that you use a program that does a open(...,O_RDWR|O_TRUNC); and lose power at that point. Well no amount of journalling or shutdown will help that one. So always creat() a new file and rename() it over the original.
When demonstrating solutions to clients I always give them a power-plug yank-test to show them it's perfectly possible and reasonable to expect a system that isn't a fragile as you suggest.
By the way, log-structured filesystems provide exactly the semantics that I describe (creat() followed by rename()) except it does it in such a way that your open(...,O_TRUNC) can be reversed due to automatic versioning.
They aren't supposed to "improve" interoperability, they are supposed to allow multiple people to write code together in the first place. If you don't write down how you break up a big software project into lots of little projects, then the people whose head that sort of information resides in become the bottleneck. Sounds familiar?
What, pray tell, do you think "interoperate" means?
the best specifications are the ones that describe something already done
Yes, and exactly those are missing from the Linux kernel: stable specifications for functionality and interfaces that are well-understood and for which writing code is routine. People aren't asking Linus to write specifications for every piece of code he likes to play around with.
This thread was not about asking Linus to commit to and document a particular set of behavior- something that's bad, but no where near as bad as that.
This thread is about defending the SCSI layered model and implementing components to fit it, instead of components that are easy to manage and understand. The SCSI specifications stink horribly, and Linux doesn't follow them.
Does this cause any real problems? Does it mean hardware doesn't work or data is lost? Absolutely not! This is about defending a stupid model by saying it's a specification.
A really good HTML-ish analogy is like saying LYNX doesn't support HTML because it sometimes ignores the <b> tag (on displays it can't make something "bold")
A really good SOAP-ish analogy is like saying a SOAP implementation isn't conforming because it doesn't produce exceptions (for example, if it were implemented in C)
A really good UNIX-ish analogy is like saying a UNIX implementation isn't conforming because it supports ISO9660 filesystems (original unix only supported 6-character filenames and that's simply how read() worked on a directory, while ISO9660 supports much longer filenames).
Who gives a shit if it's true or not. The point is that the specification is stupid, and it isn't to be followed (just) because it's a specification.
As I tried to point out: The problem is that we call other things a specification- other things that might even be actually useful, but aren't the same thing as this.
Slashdot Mirror
GNU has done very little for application developers. No GNU platform is a viable platform for shipping consumer-level applications on, yet...
I'm sorry, then what exactly is on your Mac? On every new solaris system? On every Linux machine?
When I say developers, I don't mean people who toil away. I mean people who make a business of it.
Yeah see, that's why you're a dick. You immediately mean to say that what I do, isn't business. If it always shows a profit, and it pays people their sole income to put food on the table for more than a dozen people, it's not a business because it's based on GNU.
Fuck you.
Windows is not pleasant to develop for. But the money makes it worth it.
Obviously to you. But as I kindly point out, you're nothing but shit for brains with confused half-concepts of what business is, what makes you think that you can tell me what is worth it?
New developers don't know better. Kids that come out of school simply do not know what it is like to develop on an enjoyable platform.
And it doesn't matter where half the money of that low-cost systems goes to.
Again, shit for brains.
That system would never have reached $500 with just Apple making GUI systems.
You're completely confused. I happen to have on my desk right now, a $500 modern macintosh. It's actually worth it. At the other end of my desk, a $250 Linux workstation. It's worth it too.
My neighbor has a $500 DELL. It's not worth it, not even to them. To the point where it gathers dust, and my machines get used every day.
It took the competition of Windows to make that happen.
Until you pass Go and collect a clue, don't ever suggest for a moment that Windows has ever competed with anyone. They are sub-par products by sub-par people that charge an arm and a leg (not to mix metaphores: creating more sub-par people) because of an illegal monopoly.
Tell me, kind wizard: If nobody enjoys developing on it, and nobody enjoys using it, how can ``The Money'' it possibly be worth it to anyone to write on it?
Because they're an illegal monopoly it's everywhere. Everywhere can make it worth it to some people to write for it. Being as how that everywhere is getting smaller every day, I find it easier to convince people that it isn't.
But I'm so glad it's 1998 again, and retarded monkeys like yourself can post to slashdot and remind us that you're only doing software development for real, when you do it on Windows.
As a side note, it's interesting that you point out by your own convictions that you don't do software development for real, and then intend to lecture those who by their own definitions, do.
Fuck you.
Anyone who watched the PC platform when Windows 95 came out knows better than to say that MS stifled development.
Agreed. I think it's more appropriate to say they set it back twenty years.
By creating a platform for developers,
Actually, that was GNU: By developers and for developers. Windows is probably the most unpleseant platform to develop for still in active use.
they allowed the lowly PC platform to catch up greatly to the Mac in usability
You'll end up shot if you tell a Mac person that.
Windows never came close to MacOS in terms of usability. Not to mention your leading about developers- MacOS was and still is extremely pleseant to develop for.
and bring capabilities to buyers of low-cost hardware that might never have come to them otherwise.
You mean like how almost half of a reasonable system goes into Microsoft's pocket?
There is no reason why you can't migrate 99.999% of all servers to TCPv2 and not notice a difference.
Sure there is, it's the exact same reason you cannot migrate servers to IPv6. There isn't a migration plan.
ALL software that stores IP addresses or port numbers needs to be updated to the new "format". That's what a lot of people think is the big hurdle, but it's not. It has to be done with no new "knowledge" of each piece of software.
New services are what is quoted as being the big push for new address spaces. HTTPS should've used SRV, and has a built-in time limit (whenever the new root certificates expire). HTTP should've used SRV, but no such time limit exists.
How do you upgrade clients to a system without servers, and how do you upgrade servers to a system without clients?
The only answer the IPV6 working groups can come up with is "get everyone on both until everyone's on both."
That's not a migration plan. That's billions of dollars of work for no real gain. Not when "most people" can get things like address compression a lot faster and still interoperate on both sides of the fence (albeit: with some possible workarounds for really ancient clients).
So the million dollar question is why migrate thousands of protocols and thousands of platforms for address spaces that no one has a use for, when we can migrate dozens of protocols, and plan for future ones with no change at all to most existing clients or servers, and very little change to a few.
I'm sure there are quite a few- and they should be reallocated.
Nobody will switch to IPV6 because there isn't a migration plan- there aren't proxies, there aren't anything.
IPV6 doesn't deserve to be called "Internet2" because nobody uses it. Not for Internet access.
I have no idea why methods of address compression aren't being used- like using SRV records so that we can use the additional 16-bits of ports as addressable space.
It only makes sense. Cisco has:
198.133.219/24
128.107/16
128.108/16
64.104/16
64.100/14
I count 524,544 ip addresses right there. It's pretty amazing because cisco only has 34,000
employees, or 15 IP addresses per person.
No wonder they don't want to give any addresses back. It's a lot of work to use public addresses effectively.
Meanwhile, convince everyone else to spend umpteen-trillion dollars to switch to IPv6 or only the people who want to get on the Internet in the next few years, and they don't have to do a damn thing.
Oh, and I'm almost certain cisco has other netblocks. Those are only the ones I know of off the top of my head.
You simply can't expect joe public to ever learn how to compile his kernel and even messing around with kernel modules is probably asking too much.
... in fact, almost all my hardware "just works" with Linux. I guess that's what I get for buying supported hardware.
That's a good point! Why exactly does ATI make you compile your kernel on Linux but not under Windows? What is wrong with them?
I think it's just amazing that some people can get unsupported hardware to work under Linux (you included!).
I've got some TV cards on the other hand, that don't have drivers past Win98, and simply won't work in Windows at all.
So from where I'm standing, Linux has excellent driver support. It's ATI that's a piece of shit.
Take a (non-existant) Unix only user and give them Windows. They have the same issues. Take someone fluent in spanish and transport them to India. Same problems.
Speaking as a unix-only user, I cannot use windows. It's worse because many of the Windows users have no problems using Unix around my office, but myself (and the other unix-only folk) are completely lost when it comes to Windows.
Think of this without bias. If you had been thrown into Windows XP for the first time and asked to do the same thing, would you know that Outlook is a frigging e-mail program!!!??? Its icon doesn't even have anything to DO with e-mail. Changing a date - woo-hoo! Right-click the date. Thank GOD they got that right!
In fairness: Outlook Express is what many people call Outlook. It's icon is appropriate. Users have had to explicitly install Outlook to get it- and during installation, it's made very clear what Outlook is.
UI design is flailing in the OSS community because the resources M$ throws at UI design don't exist - especially in the FOSS subset of the OSSers. Do you have millions of dollars to do user usability testing - as in the people who wouldn't volunteer freely to "beta" something - the ones that outnumber the beta testers 50 to 1. Do you have millions of dollars for focus groups and other UI related tasks?
This is confusing. You're blurring the distinction between approachability and usability. Many (most?) unix programs have far more usable and productive user interfaces than their Windows counterparts simply because when they're used, they're used a lot. Asking a programmer to do a repetitive task simply because it's easier for someone who isn't is just foolish. Programmers scratch those itches so that after thirty-years or so, they are simply so rare it's not even funny.
Now approachability is a different issue. UNIX is certainly less approachable than Windows- except perhaps in recent years. I have noticed that ten years ago, many neophites were afraid to go up and touch a unix workstation (perhaps it's because people in suspenders are scary), but nowadays, such fears are almost completely gone.
The biggest problem with approachability is that it not surprise the user- getting an error about some "Illegal Operation" one purportedly performed is a great way to scare the user- they might not come back, and because they were still in the approaching-productive phase, this hurt approachability.
Novell is targetting people that aren't in the approaching-productive phase. These people already know how to perform tasks in their domain. The goal here is to improve approachability without damaging usability- something that UNIX desktops are already way ahead of their Windows counterparts- something that would happen immediately by "copying" menus and what have you.
The difference is money. Give the same efforts that M$ puts into UI usability and testing to the FOSS folks and you'd have - well a better Windows, but definitely a much better UI.
Microsoft doesn't put the kind of money into usability testing that people think. They haven't until very recently, and overall, surprise-surprise! UNIX people are spending (collectively) more than Microsoft. Every shop that "switches" to Linux spent money and time doing usability testing- Every programmer that develops for POSIX- Every CGI- Almost every time someone is using these "new things" it's being tested.
The trick is that Microsoft already has a monopoly. People rarely test the usability of Windows- but when they do, they find it often loses! For real work, it simply cannot compare.
You forgot the Archimedes O/S, which was the first one to have a task bar, as far as I know.
I most certainly did not! I have fond memories of RISC/OS, I simply don't believe that thing qualifies as a task bar as it operates more like the dock on NeXT. (which is different than it's "task bar").
The Amiga also had a nice mechanism for associating files with programs, as well as a local registry inside the application directory for each executable, meaning that apps did not have to be installed, just copied (and they could be moved after installation).
Agreed. The Amiga clearly did this right, but while it beats Windows by years, MacOS still beat Amiga.
GNOME has something very similar.
Maybe your GNOME does, but not mine. People have developed an awful lot of muscle memory using that task bar, and GNOME is by-and-large, an excellent migration tool: my GNOME doesn't have a task bar at all.
KDE has something very similar.
KDE doesn't adopt things for being "a good user interface" and doesn't reject things for that reason either. This is probably why KDE development is so fast. FWIW, the KDE task bar (like the GNOME one), although able to make migration easier, is NOT anywhere near as bad as Windows.
OSX has something similar.
No. This is completely and totally rejected. OSX doesn't have a task bar, it has a dock, which in many ways does the things that a task bar can do right, but doesn't do ANY of them wrong. The dock doesn't work like the task bar (I can drag stuff to and from it and it does what I expect), dropping an item on a task (open or closed) has the appropiate effect
The OSX and NeXT dock is very similar- unless you use these systems. Saying the windows taskbar is like the NeXT dock is like saying the Windows command prompt is like a UNIX shell and terminal. It's not. Not even close. Not even remotely close. Not even mistakably close. Not even reasonably possible to mistake one for another.
No.
What DOESN'T have a taskbar of some description?
Besides MacOS/NeXT?
OSF/Motif, MacOS "classic", GEM, GEOS, Workbench (Amiga), just to name a few.
Note that what a taskbar makes is an omnipresent window list displaying each window as a separate element. If this window list is available on demand (instead of omnipresent), sortable, collapsable, or task-oriented (as opposed to window-grouped) then it's satisfactory.
Note that the GNOME and KDE "window list" knobs satisfy this. MacOS/NeXT is task-oritented and not a "window" (but instead an application) and not a window-list in the sense that that REALLY IS the application [as far as the user is concerned].
From:
http://h18004.www1.hp.com/products/servers/prolia
And by the way, when most of the controller hardware is physically on some disks and on an expansion card on others, blurring the distinction seems acceptable to me when we're talking about durable systems.
Simple - a journalling filesystem is designed to protect changes to the filesystem itself - not to it's contents. So in the case of a bad shutdown, it ensures that all the information about files and directories and which disk blocks belong to which files is consistent.
/tmp.
Absolutely not! Some journalling filesystems are designed to protect changes to metadata, but not all. Many consider protecting data to be prohibitively expensive, but that's not the same thing.
However, it makes no guarantees about the data contained within those disk block - if you've appended data to a file, the extra blocks will have been added to the file, but the actual data may not have been written to them.
I never append to files that I cannot live without. Rarely is it that I do it at all; my most common abuse of this is debugging logs that are easier to watch live. I also usually put them in
Troll.
1. The "taskbar". Before Windows 95 there was a concept of a window being "iconized", where the "icon" vanished if the window was open. It appears that Microsoft first made an "icon" that stayed there even if the window was open.
Err, both NeXT and OS/2 did this. Furthermore, there's a very good reason almost nobody else uses the "task bar": it's a terrible user interface.
2. Also in the taskbar, the realazation that words are more important than icons, and shrinking the icon to a more appropriate 16x16 size and making the text visible.
In OS/2, you got the entire text. Even for Modal Windows (which don't show up on the Win95 task bar). For NeXT you got a tool tip of the full text, and never an amended version (like you'll see in Win95).
3. Eliminating the artificial dividing line between the window border and the contents, so that a window displaying a uniform gray rectangle of the right color blends cleanly into the border. Although I wrote something like this myself quite a few years earlier for the NeXT, I hardly publicized it, and never saw similar graphics design until Windows.
Wow. Many MacOS and OS/2 applications did this exactly, and NeXT did it one better by getting rid of the window border itself.
4. "Combo box" where text input and multiple selection are done by the same widget. Having worked with NeXT before this, I'm pretty certain it did not have this, and never saw it on any other system either. (crappy popup implementation with the scroll bar is irrelevant to the innovation, although I really wish they would fix that...)
NeXT most certainly did have it, and so did Motif. They were uncommon with Motif, but SGI used them quite a bit.
5. Scroll wheel. The idea of having another control to scroll data on the mouse was older, but Microsoft seems to have realized that a 1-D version would provide most of the benifit without the confusion or flakiness of older attempts that tried for 2 or even more degrees of freedom.
Wrong again fanboy, both Kensington and Logitch did it with a knob, and Logitch even did it with an actual toothed wheel that was much easier to use than the Microsoft bastardization.
This is exactly why Microsoft has a patent on using a scrolling wheel as a z-index instead of as a scrolling device.
6. Having all files be "commands" in that if you double-click it examines the file (even if only the filename) and opens it with the correct program. The Mac does not count because it relied on imbedded metadata in the file, rather than an outside deciding program. Nor does #! notation in Unix exec of files, as it still requires the execute bit and does not work for files that lack this. I think a very important detail is that this idea could have been implemented 20 years earlier, it does not rely on GUI, and no CLI system ever did. A useful idea that is not realized until long after it is possible is a real indication that it is an "innovation".
First of all, MacOS doesn't work that way; the "type extension" is 4 characters (instead of three), but it's basically the same mechanism. Furthermore, multiple programs that support editing a file type are all accessible (as the creator is additionally available as another 4-character extension).
Why are these things invalid when they're clearly part of the file name?
So even if you refuse to let the Mac count for other reasons, why don't GEM, OS/2, OSF/Motif, CDE, or NeXT count?
http://list.linux-vserver.org/archive/vserver/msg0 2546.html/ browse_frm/thread/50a838e9734da325/36f7c8badcb0675 2?lnk=st&q=unexplained+reiserfs+corruption&rnum=1& hl=en#36f7c8badcb06752w are/browse_frm/thread/9193d9ab458cbc91/61101e11a18 d28b5?lnk=st&q=unexplained+reiserfs+corruption&rnu m=2&hl=en#61101e11a18d28b5
http://groups.google.com/group/mlist.linux.kernel
http://groups.google.com/group/alt.os.linux.slack
Lots of people have weird problems with reiserfs that they never have anywhere else. They also never seem to get their questions answered.
All UNIX filesystems operate in the manner that I described. It's a requirement, and is often referred to as "UNIX semantics".
The -o data=journal part IS ext3 specific. Both ext3 and jfs are theoretically safe (on Linux. BSD's FFS should also be safe due to ordering). Reiserfs is NOT safe. XFS probably is, but the manuals should be checked.
I don't see why you would need a system shut down immediately.
I don't see why you wouldn't want a system that could shut down immediately. I mean, a TiVO should just eat all my shows if lightning strikes my house, right?
I find that weird stuff happens once you give a system to a customer that runs on a computer, and looks like a computer, but isn't a computer. These people don't know how to shut things down, and they become extremely irritated when you tell them that they have to do some kind of weird magic.
Especially after they've seen my demonstration and know that they don't
There exist IDE disks that ignore this setting.
Compaq Smart Array 5300 family uses a battery to accomplish this very thing. They advertise it too.
Do you have any idea how long it would take to flush out even a megabyte of small random writes? You'd have to slap a battery on the disk, and a 12V battery at that. Or use NVRAM for the cache, which is what good RAID controllers do.
Why would you need a battery exactly? Many drives have such a small on-disk cache that a few capacitors have enough power to flush the cache.
Not atomic snapshots. Not that everyone needs this, but if you do, it does require FS support. Netapp's file system, for instance, supports atomic snapshots. Very nice for hot backups of DB data files, for example
You don't need the filesystem itself to be designed for it. If the filesystem supports an unmount operation, LVM could eventually do it. XFS's freeze operation is a good example of this.
I use Reiserfs, not ext2fs
Well, since Reiserfs doesn't do what you want, why not switch? Or consider adding the support you DO want to Reiserfs? Or pay someone to do it!
Also I do not like the idea of a user process directly accessing the FS. Probably good enough for a virtual machine environment where you can stop the machine and run the program, but this is for a live filesystem.
You're kidding, right?
What do you think fsck does?
For swap, it would be possible to zero it on boot and shutdown, but it takes a bit too long on my 2GB swap, and also it would not help against forensic analyzers who are careful not to boot the system.
What you really seem to want is an encrypted block device.
When I delete a file, maybe I want it to be nonrecoverable.
Log structured filesystems normally come with a garbage collector that cleans up things like this.
[secure deletion] Does such a thing exist for Linux?
http://intgat.tigress.co.uk/rmy/uml/sparsify.html
Exactly like a tape drive. Because of this, you get all the benefits of a type drive: straightforward implementation, guaranteed write times, and inherently transactional.
This is a good thing.
Correct me if I'm wrong, but I was told that ext2/ext3 would keep a file whole
You're wrong. Firstly, fragmentation isn't necessarily a bad thing. Generally collecting data as long as you're going the same direction (continuous sectors, or alternating) is very fast. Fragmentation is a very good thing in specialized systems where you need a guaranteed read time (as opposed to fast if possible, slow if not).
No it's not. On modern disks, switching heads is instantaneous because it's an electronic (not a mechanical) operation. Moving the head to the next physical sector is fast, but moving it "backwards" is slow (you have to do a full revolution). Extending to a different track is also slow.
Certainly, there is some aspect of the geometry that can make seeking faster.
It has something called 'snapshots', which seems to mean that you can work off of a partition, but seperately load up the version of that partition you had before you last had a power failure, or whatever went wrong.
Snapshots are easy to get without filesystem support (LVM).
* Minimal damage to file data and system consistency on hardware failure
Log-structured filesystems do NOT do this. For this you need RAID.
* Correctly ordered data and meta-data writes
Again, not inherent to a log-structured filesystem. In fact, every filesystem should have a correct way to perform ordered writes, and as long as recovery is done by a knowlegable system, most filesystems can be trivially converted to journalled filesystems.
* File and inode blocks are managed by a B-tree structure
Again, not inherent to a log-structured filesystem. Many filesystems use this method because it's easy, but note that B-trees (or B+Trees) aren't necessarily faster for real-world activity, and a poorly balanced tree can even provide much worse performance than a naive approach.
Yes this happens in reality.
VMS has done this for years, and it IS great. But really, you should consider using one of these log structured filesystems (like what the article is about) because it already does exactly this.
I am probably not the only one to come back to an old file saved years ago only to find a glitch in it. I noticed it with a couple of movies. Movies I know were perfect as I watched them without copying them. So the only explanation is that part of the disk got corrupted.
That doesn't follow. Perhaps your filesystem isn't safe, or configured to be safe.
I've had a UFS system eat entire (old) directories due to the directory being updated and an untimely crash.
Sure it does: mount -o sync,data=journal
Also, your disk will probably have a cache that is lost when you remove power. Whatever is in the cache will also be lost.Hogwash. Disks that have such a cache have no command that tells them to actually flush their cache. They simply flush the cache whenever convenient or when power supply is lost to the disk.
So your file system may be intact, but your practices will probably destroy data.That makes no sense. Either my files system is intact, or it isn't. I reject the notion that my file system can be intact but that data is destroyed.
What's more likely is that you use a program that does a open(...,O_RDWR|O_TRUNC); and lose power at that point. Well no amount of journalling or shutdown will help that one. So always creat() a new file and rename() it over the original.
When demonstrating solutions to clients I always give them a power-plug yank-test to show them it's perfectly possible and reasonable to expect a system that isn't a fragile as you suggest.
By the way, log-structured filesystems provide exactly the semantics that I describe (creat() followed by rename()) except it does it in such a way that your open(...,O_TRUNC) can be reversed due to automatic versioning.
I've never used anything but reiserfs. If a distro won't support it, I won't use that distro, simple as that. It's a really nice filesystem.
Funny. I've used xfs, ext[23], reiserfs, jfs, and linlogfs, and reiserfs is the only thing that actually ate my data.
They aren't supposed to "improve" interoperability, they are supposed to allow multiple people to write code together in the first place. If you don't write down how you break up a big software project into lots of little projects, then the people whose head that sort of information resides in become the bottleneck. Sounds familiar?
What, pray tell, do you think "interoperate" means?
Yes, and exactly those are missing from the Linux kernel: stable specifications for functionality and interfaces that are well-understood and for which writing code is routine. People aren't asking Linus to write specifications for every piece of code he likes to play around with.
This thread was not about asking Linus to commit to and document a particular set of behavior- something that's bad, but no where near as bad as that.
This thread is about defending the SCSI layered model and implementing components to fit it, instead of components that are easy to manage and understand. The SCSI specifications stink horribly, and Linux doesn't follow them.
Does this cause any real problems? Does it mean hardware doesn't work or data is lost? Absolutely not! This is about defending a stupid model by saying it's a specification.
A really good HTML-ish analogy is like saying LYNX doesn't support HTML because it sometimes ignores the <b> tag (on displays it can't make something "bold")
A really good SOAP-ish analogy is like saying a SOAP implementation isn't conforming because it doesn't produce exceptions (for example, if it were implemented in C)
A really good UNIX-ish analogy is like saying a UNIX implementation isn't conforming because it supports ISO9660 filesystems (original unix only supported 6-character filenames and that's simply how read() worked on a directory, while ISO9660 supports much longer filenames).
Who gives a shit if it's true or not. The point is that the specification is stupid, and it isn't to be followed (just) because it's a specification.
As I tried to point out: The problem is that we call other things a specification- other things that might even be actually useful, but aren't the same thing as this.