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

[fwgx]

Originally posted by spiderbaby1958
The simpler a gui interface is, the less flexible and powerful, and the more clicking you have to do to accomplish a task. When you know how to use the command line, you can cut through a lot of gui "red tape".

Not so. You only have to look as far as MS products to see that they are the masters of flexable, powerful GUI design. Stating "more clicking" as a bad thing compared with remembering abstract commands off by heart and actually having to type them out exactly, precisly and without error in full sounds a bit scewed. I have yet to see any problem that cannot be implemented well in a GUI, now it may not have been but that's not the point when arguing against GUIs in general. Now I'll hapily argue that Linux is a terrible OS when it comes to it's developers creating decent GUIs. They are badly designed, inconsistent, confusing, non-intuitive and many many many other bad things that anyone that knows anything about GUI design could spot in less than 10 mins of using the system.

Having no GUI means there is no choice on what to use and is a close minded, isolationist and elitist position to take.

[xzxzzx]

Phily, while I agree that it is possible to make a powerful and simple GUI interface, you simply can't match the power of a bash shell (without some fundamental changes to how GUIs operate).

For example, can you explain how to do something like:

1) With case sensitivity, find all files with the word "mouse" in them.
2) In those files, if they have at least 1 instance of the word "elite" in them, change "elite" to "1337", and "owned" to "pwned".

All one really needs to remember here is the name of appropriate commands to do something like this. First, to find the appropriate files, "find". I do "find --help", and get:

code:
legolas root # find --help

Usage: find [path...] [expression]

default path is the current directory; default expression is -print

expression may consist of:

operators (decreasing precedence; -and is implicit where no others are given):

      ( EXPR ) ! EXPR -not EXPR EXPR1 -a EXPR2 EXPR1 -and EXPR2



      EXPR1 -o EXPR2 EXPR1 -or EXPR2 EXPR1 , EXPR2

options (always true): -daystart -depth -follow --help

      -maxdepth LEVELS -mindepth LEVELS -mount -noleaf --version -xdev

tests (N can be +N or -N or N): -amin N -anewer FILE -atime N -cmin N



      -cnewer FILE -ctime N -empty -false -fstype TYPE -gid N -group NAME

      -ilname PATTERN -iname PATTERN -inum N -ipath PATTERN -iregex PATTERN

      -links N -lname PATTERN -mmin N -mtime N -name PATTERN -newer FILE



      -nouser -nogroup -path PATTERN -perm [+-]MODE -regex PATTERN

      -size N[bckw] -true -type [bcdpfls] -uid N -used N -user NAME

      -xtype [bcdpfls]



actions: -exec COMMAND ; -fprint FILE -fprint0 FILE -fprintf FILE FORMAT

      -ok COMMAND ; -print -print0 -printf FORMAT -prune -ls





Report bugs to <bug-findutils@gnu.org>.

Ok, so our command will be something like:

code:
find /tmp/1337/ -name mouse -exec (do something)\;

Now, I need to make sure there is an instance of "elite" in the files. "grep" should fit the bill:

code:
legolas root # grep --help

Usage: grep [OPTION]... PATTERN [FILE] ...

Search for PATTERN in each FILE or standard input.

Example: grep -i 'hello world' menu.h main.c



Regexp selection and interpretation:

  -E, --extended-regexp     PATTERN is an extended regular expression

  -F, --fixed-strings       PATTERN is a set of newline-separated strings

  -G, --basic-regexp        PATTERN is a basic regular expression

  -P, --perl-regexp         PATTERN is a Perl regular expression

  -e, --regexp=PATTERN      use PATTERN as a regular expression

  -f, --file=FILE           obtain PATTERN from FILE

  -i, --ignore-case         ignore case distinctions

  -w, --word-regexp         force PATTERN to match only whole words

  -x, --line-regexp         force PATTERN to match only whole lines

  -z, --null-data           a data line ends in 0 byte, not newline



Miscellaneous:

  -s, --no-messages         suppress error messages

  -v, --invert-match        select non-matching lines

  -V, --version             print version information and exit

      --help                display this help and exit

      --mmap                use memory-mapped input if possible



Output control:

  -m, --max-count=NUM       stop after NUM matches

  -b, --byte-offset         print the byte offset with output lines

  -n, --line-number         print line number with output lines

      --line-buffered       flush output on every line

  -H, --with-filename       print the filename for each match

  -h, --no-filename         suppress the prefixing filename on output

      --label=LABEL         print LABEL as filename for standard input

  -o, --only-matching       show only the part of a line matching PATTERN

  -q, --quiet, --silent     suppress all normal output

      --binary-files=TYPE   assume that binary files are TYPE

                            TYPE is 'binary', 'text', or 'without-match'

  -a, --text                equivalent to --binary-files=text

  -I                        equivalent to --binary-files=without-match

  -d, --directories=ACTION  how to handle directories

                            ACTION is 'read', 'recurse', or 'skip'

  -D, --devices=ACTION      how to handle devices, FIFOs and sockets

                            ACTION is 'read' or 'skip'

  -R, -r, --recursive       equivalent to --directories=recurse

      --include=PATTERN     files that match PATTERN will be examined

      --exclude=PATTERN     files that match PATTERN will be skipped.

      --exclude-from=FILE   files that match PATTERN in FILE will be skipped.

  -L, --files-without-match only print FILE names containing no match

  -l, --files-with-matches  only print FILE names containing matches

  -c, --count               only print a count of matching lines per FILE

  -Z, --null                print 0 byte after FILE name



Context control:

  -B, --before-context=NUM  print NUM lines of leading context

  -A, --after-context=NUM   print NUM lines of trailing context

  -C, --context=NUM         print NUM lines of output context

  -NUM                      same as --context=NUM

      --color[=WHEN],

      --colour[=WHEN]       use markers to distinguish the matching string

                            WHEN may be `always', `never' or `auto'.

  -U, --binary              do not strip CR characters at EOL (MSDOS)

  -u, --unix-byte-offsets   report offsets as if CRs were not there (MSDOS)



`egrep' means `grep -E'.  `fgrep' means `grep -F'.

With no FILE, or when FILE is -, read standard input.  If less than

two FILEs given, assume -h.  Exit status is 0 if match, 1 if no match,

and 2 if trouble.



Report bugs to <bug-gnu-utils@gnu.org>.

So:

code:
find /tmp/1337/ -name mouse -exec grep elite {} \; 

Now for the replace. I'll use sed (this one you just have to know, though it's easily found with a Google search):

code:
find /tmp/1337/ -name mouse -exec grep elite {} \; 

-exec sed 's/elite/1337/g' {}\; -exec sed 's/owned/pwned/g' {}\;

(broken into two lines for the forum's sake)

Yes, this is more cryptic than using a GUI, but you'd just be opening the second file in Windows when I hit "enter", assuming I didn't know the syntax offhand anyway (which, for this simple of a command, I do). The point is that while a GUI becomes slightly more powerful over use via familiarity, a command line becomes vastly, vastly more powerful.

Can you envision a GUI producing this kind of flexibility and power? I can't. Not without some sort of major shift in GUI style. What's really missing is stdin and stdout. Different GUI pieces don't fit together.

I don't, however, particularly disagree with you on any point you made Phily, as when considering the average user, this would be totally unworkable, and you're right, linux GUIs have a long way to go (I'm pretty familiar with GUI design myself - I've read GUI design books for fun ).

[zootm]

GUI interfaces can be made modular and powerful, but yes, text-based ones are very good for combining. The reason for this is simple - streaming. They're text interfaces, they take in and give out text. It's simple to make them parse things because of this. It's just completely pointless for the average user.

Incidentally, although I know a few GUI-based tools that it's possible to do your task in, it would require the use of text-based tools, which kinda defies the point. For the sake of finding a quick GUI-based solution, though, using the tool jEdit you could make a GUI-based solution, the only part of which where text-based stuff is needed is a BeanShell macro to close all buffers not containing "elite". It wouldn't be any more complex than using the text tools.

The point is, though, for 99% of uses of computers, this sort of nonsense is completely unnecessary. And it's not like bash and these tools aren't available for every modern computer platform (I used to code on Linux exclusively, but since I started using Cygwin there's no actual difference).

[fwgx]

Depending on how many files you're expecting to change I would use the "find in files" option in something like EmEdit to get a list of files and then click on the file in the list to open it and then use the replace command. Simple.

Although I see your point, I don't think people in general spend their days editing pure text files. Heck, I do and I extremely rarely come up against anything I can't do in a GUI or with a recorded macro in VS6. And more often than not it is quicker to do it all manually instead of read the help file for one command, try and find out a crypticly named utility that does what you want. Learn to use it, pipe it into something else and, yadda yadda yadda.

I can see GUIs doing just that kind of thing very well. You just have to create a workflow program that groups all programs into categories such as text editing, graphics etc. You drag and drop programs onto the workbench, connect up flow lines, add some filters and conditional logic and you're done.

[zootm]

See, that's an interesting concept, Phily, I was wondering if that would work. The main problem is that all the different programs have non-homogeneous modes of dispatch, so it'd be hard (without command-line switches for said GUI tools ).

[xzxzzx]

Originally posted by Phily Baby
I can see GUIs doing just that kind of thing very well. You just have to create a workflow program that groups all programs into categories such as text editing, graphics etc. You drag and drop programs onto the workbench, connect up flow lines, add some filters and conditional logic and you're done.

This is the kind of thought I was trying to stimulate.

Still, while my example may be artificial, it is an example that could be far more easily accomplished with a text interface. Regexes are my best friends. Recently, I had to handle a mail server that was misconfigured and acting as an open relay - I decided that I'd get rid of the email that was in the outgoing queue that had come from the relatively few other servers on the net that had discovered this one.

It was easily done with a find command:

code:
find /var/qmail/queue/mess/ -exec grep "^Received:.*(spammer's ip)" {} \;

-print -exec ~/mymessagedeletescript.sh \;

I'm sure there are GUI-based tools available that would perform something like this, but I doubt there are any that would easily allow me to tweak my command. For example:

code:
find /var/qmail/queue/mess/ -exec grep "^Received:.*(spammer's ip)" {} \; -or

-exec grep "^Subject: WANT A BIG PEN[I1]S. CL[I1]CK HERE" {} \;

-print -exec ~/mymessagedeletescript.sh \;

etc...

While I understand your point about cryptic commands, Phily, you should see a competent Unix administrator who's been using those commands for a while. It's fucking magic.

Plus, it looks really good to your boss who has no idea what those strange things on your screen are, and is amazed at your fingers flying over the keyboard and your comprehension speed as you use auto-complete and are only reading the one relevant piece of data from a list of 50 .

Efficiency brings on a whole new meaning. Want the PID/image name for the program that's listening on port 80?

code:
legolas root # netstat -tlnp | grep ":80"

tcp        0      0 0.0.0.0:80              

0.0.0.0:*               LISTEN      2661/apache2

How many lines of code are in my project's .txt files, anyway?

code:
legolas source # find -name "*.txt" -print0 | xargs -0 cat | wc -l

2961

Hmm, that seems high. What if I don't count blank lines?

code:
legolas source # find -name "*.txt" -print0 | \

xargs -0 cat | grep --invert-match "^ *$" | wc -l

2863

That's better. By the way, if the file names didn't include spaces or wierd symbols (like a file named "bl*ah.txt"), the commands would be more like:

code:
find -name "*.txt" | xargs cat | wc -l

and if you didn't have too many .txt files to overwhelm your shell (253?), you could do:

code:
wc -l `find -name "*.txt"`

As for:

Originally posted by Phily Baby
And more often than not it is quicker to do it all manually instead of read the help file for one command, try and find out a crypticly named utility that does what you want. Learn to use it, pipe it into something else and, yadda yadda yadda.

You're right, it's often faster the first time, and the second time, and even maybe the third time, but there eventually comes a point where you're less productive than if you'd lost the time learning. And it's not like these commands have exactly precise applications - once you've learnt how to use grep, or find (not to mention sed or awk)...

I used to view unix commands as I believe you do, that they're cryptic commands with limited use, and that it takes huge investments of time before you get any use at all out of them. It's not true, though - learning just a few commands, you have amazing power at your fingertips. It's not a mistake, these commands have been around for a very very long time in the Unix world.

[zootm]

The thing about UNIX commands is that they fit in with the UNIX paradigm - everything's a file, files are usually text. It works so well by design. The reason they're useful is because people decided to design things so that tools like that would be useful, if that makes sense.

The commands tend to be less useful on Windows because configuration and so on simply isn't stored as plaintext, and the "everything's a file" paradigm isn't used (since it has less meaning in a GUI setting). It's just design choices.

[whiteflip]

Originally posted by zootm
The thing about UNIX commands is that they fit in with the UNIX paradigm - everything's a file, files are usually text. It works so well by design. The reason they're useful is because people decided to design things so that tools like that would be useful, if that makes sense.

The commands tend to be less useful on Windows because configuration and so on simply isn't stored as plaintext, and the "everything's a file" paradigm isn't used (since it has less meaning in a GUI setting). It's just design choices.

Damn Regsitry. Whats so wrong with ini files anyway?

[zootm]

What's wrong with the registry? It's as organised as .ini files are... The only real problem is cross-platform compatibility.

I used to be convinced by the "single point of failure" angle, but then I realised that ~/.* is basically the same as the single-user registry. I believe GNOME has its own registry-like construct now?

[fwgx]

There's no reason that the registry can't be distributed and simply backed up to a remote domain server or something. I like the registry as an idea, it's much more preferable to flat files imho. I do LOVE the idea of a SQL based OS though. Now with that you get power, simplicity and security. I so hope MS get it to work mmmmmmm.

[zootm]

WinFS isn't going into Longhorn (well, not relationally-based, anyway) any more, apparently. Bit of a bummer, really.

I'm not sure if SQL would really be sufficient for a filesystem, it's quite limited (with the exception of the theoretical, unsupported flavours). RDF seems more relevant (although I think it might be slower).

[xzxzzx]

Originally posted by zootm
What's wrong with the registry? It's as organised as .ini files are... The only real problem is cross-platform compatibility.

I used to be convinced by the "single point of failure" angle, but then I realised that ~/.* is basically the same as the single-user registry. I believe GNOME has its own registry-like construct now?

Ever tried editing the registry of a non-bootable Windows install? How many helpful comments have you seen in the registry? Backup of /etc/ (cp -r /etc/ /mybackup/) is a hell of a whole lot easier than backing up the registry (and a hell of a whole lot more complete in terms of machine-wide configuration).

It's also easier to tar /etc/apache/ and email it than to find the relevant registry entr(ies) and then export them. On top of all that, registry entries are often not the only place an application stores data - it's far more common to have a pointer in the registry to a configuration file when there is any complexity at all in the configuration.

The only advantage to the registry is that it's easier to change on-the-fly (in memory), so applications can often be reconfigured immediately (no restart), though since you're rarely actually changing the registry through anything but a software-specific GUI anyway, it's more of a software design issue than anything to do with the registry.

Flat files are significantly closer to writing a script (and many of them actually are scripts) to configure something, so you get useful things like the ability to include other files, to comment out sections in a standard and easily understood way (try that in the registry), to note WHY a particular setting is a certain way, to do useful things like take a setting from a remote machine, automagically.

And I'm not making this up. From Microsoft's website regaurding the registry:

The registry can take up a large amount of space, and a very large registry can slow the overall system performance. So to save space, you should minimize the number of keys because a key consumes more space than a simpler entry. If you need to store a logically related group of data, you should figure out a way to describe them in as flat a structure as possible and use as many entries as possible.

and

For all these reasons, and to improve the overall efficiency, the Windows 2000 Application Specification reduces the circumstances in which you need to use the registry. The specification suggests that you use files instead of entries when the amount of data is larger than 2KB.

So even Microsoft pushes toward using flat-as-possible structures and files instead of registry entries (for over 2KB).

Originally posted by Phily Baby
There's no reason that the registry can't be distributed and simply backed up to a remote domain server or something. I like the registry as an idea, it's much more preferable to flat files imho. I do LOVE the idea of a SQL based OS though. Now with that you get power, simplicity and security. I so hope MS get it to work mmmmmmm.

There's no reason that /etc/ (and any other part of a linux machine - kernel excluded?) can't be distributed and simply backed up to a remote server or something. I like flat files as an idea, they're infinately more reliable. I do LOVE the idea of a flat-file based OS. With that, you get power, simplicity, security, and reliability. I so hope no one tries to replace it with needless complexity.

[shakey_snake]

Originally posted by zootm
WinFS isn't going into Longhorn (well, not relationally-based, anyway) any more, apparently. Bit of a bummer, really.

DMR'ed replica of XP coming right up!

[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

[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]

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.

[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]

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

[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]

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.

[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.

[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.

[spiderbaby1958]

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.

[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]

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.

Originally Posted by spiderbaby1958

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.

[DJ-Garybaldy]

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

Thats going to make life interesting.

[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.

[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