Windows Palladium, the end of privacy as we know it.

[Wineroz]

Until a days comes that it does not anymore...

You know- for your safety and convenience with a mandatory upgrade performed at some very inappropriate time

[sverm]

While there won't be a 32-bit version of the OS, the 64-bit version will still support 32-bit applications, much like today's x64 architecture does.

[DJ-Garybaldy]

I'm hearing rumours about Windows 11... apparently 32bit software isn't supported on it.

Thats going to make life interesting.

[spiderbaby1958]

This is pretty much the exact moment when I decided to migrate to Linux, almost 20 years ago. And I did it! The last Windows that I've used was XP. Last night I got the idea to see if this forum, and this post, still exist.

You know, it doesn't really matter if palladium is the end of privacy or not. Clearly the technology is a step in that direction, and the next time Osama gets lucky, the government might be quite willing and able to take us the rest of the way. We need to think about the future. I don't know a damned thing about Linux, but it's obvious that I'm going to have to make the effort. Why would anybody NOT be pro-linux and antiwindows? Paying 300 dollars to the world's richest man is a good thing because... ??? Letting Bill Gates dictate to us how we can run our computers is a good thing because...???

Do we want the future to be open source, where everyone can contribute and profit, or do want a big windows logo stamped on the future?

I just read in CNET about how microsoft is bankrolling a lobbying group that is trying to stop the trend toward adoption of open source OS's by governmenmts trying to save money. They're calling it the coalition for choice or some such thing. How's that for corporate doublespeak? Microsoft lobbying for choice is like Jerry Falwell lobbying for gay rights.

[rockouthippie]

HD-DVD and Blue Ray discs have phone home DRM capacity, but they are not using it. The FCC nixed the broadcast flag.

While we are finding DRM invading, the DRM happy have had to back off quite a bit.

Next-Generation Secure Computing Base (formerly called Palladium) has positive possibilities. Consumer pressure should keep George Orwell from happening.

I expect that your VCR, Tivo and unencrypted MP3 collection will play for some time to come. Even if this was a product, it would first be adopted for secure business environments. You won't see anything like it for consumer desktops for years.

[spiderbaby1958]

Happy anniversary to me!

Originally posted by spiderbaby1958
As for myself, I have decided: f**k Microsoft. (Hey there's something wrong with my keyboard, let me try that again FUCK MICROSOFT! (There, that's better.) Lately, I've been thinking of dabbling in Linux, but now I'm planning on making Mandrake Linux my primary OS, the sooner the better.

Five years ago this month! I chose the road less travelled, and that has made all the difference.

Of course, Mandrake is now Mandriva, and I've moved on to Debian and openSUSE. Oh what fun it has been.

[CaboWaboAddict]

Originally posted by zootm
I take it you're referring to isolating the data from that of other applications?

My "plan" (i.e. weird solution thing in my head) isn't identical to the registry, and has its own ways of getting around this. I'd still err towards the registry and then just tell them not to touch the entries in it, though.

Yeah, someone in sales told some of the customers that my software stores part of its configuration in the registry. SO they went dickin' around in there and trashed the whole system (not just my software), then they wanted me to straighten it out.

On the next release of each of my packages, I'm taking it back to INI files.

[xzxzzx]

Originally posted by zootm
Some systems necessitate complex settings, though, and any generalised system should allow them in simple ways. It is trivially easy to automatically parse a file like the one you mention into XML, but I agree that it adds an extra layer of complication. And I don't agree with using scripts for representation -- it's not really standard in any way, and if nothing else nobody will agree on a language to use.

What I'd favour would replace /etc/, and I feel I have my reasons. This comes into why it seems like a "zen crime", though -- it breaks the UNIX file metaphor. "Everything's a file, files you can edit are text" is basically the system upon which UNIX is based, and it works well with the systems that were available at its inception. I do feel, however, that we have better technologies available now, and it would be very nice if we could build a more modern system design from them. Breaking compatibility, or moving to a different system, will always have vehement complaints from users of the current systems, though. And sysadmins are perhaps the most zealous users of all. You could just move everyone to a compatible configuration and merge the XML file structures to configure (GConf does something similar, but with non-standard formats too).

It is something I'm genuinely interested in, though, and I do like to hear well thought-out criticism of ideas. As for your design quote, though, my argument is that what we'd be taking away is a myriad of incompatible configuration formats and so on.

Ok, I'm going to present a 5-minute counter-argument. This is just everything I can think of that I don't like about your solution, because I only have 5 minutes to post.

First, everything-is-a-file is a perfectly valid design philosophy (even today), because it's so damn close to nothing that it's near perfect.

Second, and I don't know exactly what you're proposing, but let's say you're going to have a big XML file which stores configuration data. How can you reasonably keep that thing secure and fast and reliable and recoverable?

Third, while it's admirable to want to have one configuration format, is that going to be able to be simple enough that it's going to be able to be edited by hand? Or is it going to be 12 levels deep before you can even find application data?

Fourth, while it's nice to have a GUI for these things, and that would mitigate some administration-added-complexity rantings I've been tempted to throw in here, how well are you going to be able to edit it

The problem I see is that a registry is basically a duplication of a file system. With a file system, you've already got security, reliability, and speed. The only thing you're missing is complexity, and I don't think that's a particularly bad thing. If you make complex configurations hard to implement, that means it's easier to simplify configuration options than to build your own configuration system.

Finally, when you're trading complexity for simplicity, you have to consider when the complexity/simplicity is going to show up. If you're complicating common operations (99.9%), and simplifying rare operations, then you'd better well be eliminating a HUGE complexity in your rare cases.

From what I can tell, "vi /etc/sshd" is far, far, FAR more common than anything you'd ever need a database/XML thing to do with more simply.

And now I must go.

[zootm]

I take it you're referring to isolating the data from that of other applications?

My "plan" (i.e. weird solution thing in my head) isn't identical to the registry, and has its own ways of getting around this. I'd still err towards the registry and then just tell them not to touch the entries in it, though.

[CaboWaboAddict]

Originally posted by zootm
What sort of tricks can they do with the registry that they can't do with INI files?

Like trashing it, then calling me to help them fix it.

It is just as easy and just as efficient to use an INI file - and a hell of a lot less dangerous when your dealing with computer illiterates.

[zootm]

What sort of tricks can they do with the registry that they can't do with INI files?

[CaboWaboAddict]

I migrated from using INI files to using the Registry. Now I'm going back to using INI files. Too many issues with customers trying tricks with the Registry - I don't need that kind of support hassles!

[zootm]

Some systems necessitate complex settings, though, and any generalised system should allow them in simple ways. It is trivially easy to automatically parse a file like the one you mention into XML, but I agree that it adds an extra layer of complication. And I don't agree with using scripts for representation -- it's not really standard in any way, and if nothing else nobody will agree on a language to use.

What I'd favour would replace /etc/, and I feel I have my reasons. This comes into why it seems like a "zen crime", though -- it breaks the UNIX file metaphor. "Everything's a file, files you can edit are text" is basically the system upon which UNIX is based, and it works well with the systems that were available at its inception. I do feel, however, that we have better technologies available now, and it would be very nice if we could build a more modern system design from them. Breaking compatibility, or moving to a different system, will always have vehement complaints from users of the current systems, though. And sysadmins are perhaps the most zealous users of all. You could just move everyone to a compatible configuration and merge the XML file structures to configure (GConf does something similar, but with non-standard formats too).

It is something I'm genuinely interested in, though, and I do like to hear well thought-out criticism of ideas. As for your design quote, though, my argument is that what we'd be taking away is a myriad of incompatible configuration formats and so on.

[xzxzzx]

Sorry for my absence. To quote one of my favorite design quotes:

A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.

There is not necessarily anything wrong with a standardized configuration format. However, I do not think at all that this means that one should leap to something like a registry or what have you. Configuration files which are actually scripts seem like the best way to go to me. There's no reason a glorified script editor GUI couldn't be made.

A file named after the system process it configures in /etc/ is pretty damn standardized, though it does somewhat break down - it's not always a file named after such in /etc/.

I suppose my objection to a registry is more of a instinctual sort of thing - it seems a zen crime.

It seems this in two ways: For one, it forces program designers into a specific format (forcing designers to consider things: good. forcing designers to do things: bad). For the other, having something like an XML store seems like unnecessary complexity, without adding the power that simply standardizing on bash (or whatever) as a configuration interpreter would entail. XML lends itself to complicated settings, but then, I don't think that's exactly a good idea. If your configuration file is expected to look like:

code:


# Use KEYMAP to specify the default console keymap.  There is a complete tree

# of keymaps in /usr/share/keymaps to choose from.  This setting is used by the

# /etc/init.d/keymaps script.



KEYMAP="us"



# Should we first load the 'windowkeys' console keymap?  Most x86 users will

# say "yes" here.  Note that non-x86 users should leave it as "no".



SET_WINDOWKEYS="no"



# The maps to load for extended keyboards.  Most users will leave this as is.



EXTENDED_KEYMAPS=

#EXTENDED_KEYMAPS="backspace keypad"

That means that your configuration file is going to need to be that simple, or you're going to have to design a more complicated system. Every complexity that you make easy on a designer is going to be used, probably far more often than it should be.

Anyway, I'm tired, I'll say some more later.

[zootm]

xzxzzx - for my exact feelings on the subject of registries and so on, please see here* and the subposts thereof. I know that's a copout, but I can imagine it will save a lot of time in the long term.

Secondly, the pro-registry arguments you cite are all from Microsoft (which obviously makes sense, but do you have a good reason for a single, easily-recognised repository of setting data? I'm aware that it's more "efficient", but it's not a significant loss in 99.999% of cases, particularly in context. My argument isn't for The Windows Registry, it's for a registry-like data store which would standardise settings information to a degree. Please argue against that and not the Windows registry. I'd be very interested to hear your views in particular, and anyone's views in general, of this sort of stuff.

* The resolution of which was '...it will be interesting to see if you dev types can make us bitchy admin types happy with what just might be a not bad idea. Till then "worse is better".' from the remarkably nice-to-deal-with opponent to my ideas