Of course.

A year ago, I had an altercation with a car. Split my right femur. Car drivers fault.

Safer? Embed glass in the dashboard of cars, no airbags, no seatbelts. Force car drivers to pay attention.

Because, honestly, bikes are not the problem -- cars are.

Cars get their own highways, and, as a cyclist, I am forced to share non-highway roads. Average speed through my city? 27 kmph. So, reducing the speed from 60 kmph to 50 kmph would also help (and, as a car driver, there is still the choice to go 100 kmph on the highway!).

Not true. There are organizations that specialize in migrations, and the per-week costs are no where near 10,000/consultant.

But... the grandparent poster DIDN'T put a windowing system on the server!

virt-manager is a pretty simple X client, and the GUI is solely on your workstation. No GUI on the server at all. And, if that's what YOU do, you also don't have a GUI on the server:

[myworkstation] $ ssh -X myname@myserver
[myserver] $ virt-manager ... and virt-manager appears in a window on your workstation.

clicky, clicky, happy.

Folks - that's ALL there is to it. Except... myserver can be something completely different - A Solaris box, AIX, HP-UX, IRIX.

But, we get farther away... The Solaris application that has it's display on my workstation cannot use notifications (which should have been designed as an X extension, but the kids didn't know...). XBell seems to be deprecated. Without hackery, the xterm (that may be running on that AIX box) can't make a sound on my workstation (using that newfangled "pulse" thing). It can be hacked to work, though.

RDP? Will that help me? Probably not -- I don't log in to a single system that supports RDP.

Local X clients on my workstation can do fancier stuff, off course. But all the applications render to my X server, and the compositing happens locally, anyway. My Solaris and AIX X applications can push bitmaps, but they generally don't. Those applications really don't care.

The biggest problems with X today? Notifications. Other crap that uses other inter-application communications (like DBUS) instead of X. Deprecation of XBell. Network sound that is far too complicated.

If it takes "Wayland" to solve this, make sure that there is a simple proxy that can easily be deployed that lets me use those X applications. However, that doesn't fix my X issues, and just adds an additional layer.

How does this stack up? About the same as if I run an X Server (say Hummingbird, or Cygwin) on a Windows workstation. Interesting, that...the PRIMARY reason I (personally) run Linux as a workstation OS is to allow me to use an X Server as my primary display.

If that were not the case, I would just leave Windows (whatever version) on my workstation, and start from there.

Well... that and being able to simply recompile my code to run on the workstation or the servers as appropriate. I generally use Tk as a GUI for applications anyway (at least for one-off apps).

Now you've gone and done it!

I am off building an ARM to Atom binary compiler, and see what that gives.

To move the cursor with a touchpad, you "swipe" in a direction.

You need to move the cursor to select with a mouse or a touchpad. On your iPad ("iTouch"??), you just touch; there is no need to move the cursor.

Which means swipe is separate from move on the "iTouch", and is not on the authors system (may be the system vendors configuration error, or Microsofts, or a driver issue, doesn't matter because it rendered the system unusable),

Gothmolly

Evolution works fine as a working Exchange client. Email, calendaring, notes, address book.

LibreOffice works as a "drop-in" (quoted because of below) replacement for Microsoft Office (INCLUDING VISIO).

Macros need conversation.

"Linux on the desktop" is viable. Won't be popular, anyway. Mostly because it will be rejected without further thought by most people.

Bold statement, there.

To rephrase (and it's really not stated clearly) - you don't think a Linux Vendor has produced a packaged Linux based OS that does not require a "command line".

Wrong.

- Android (Linux)
- Fedora (16, 17, and as far back as 8). Gnome or even XFCE (Linux)
- Mac OS X (BSD)

Now, I am glad that you qualified your statement with "that Windows has a button for". So that's two "Linux OSs", and one "BSD OS" over a bunch of versions.

I'm surprised about Ubuntu (not that I am all that aware of it).

It is clear that you consider command line usage a "flaw".

But, to supply a typical example: someone wanted to know how to change a user's UID and GID (Unix/Linux user id and group id). The answer?

Log in as root, and "vi /etc/passwd". Find and change the line referencing the user. "vi /etc/group" and do the same for the group.

Type "find / -uid 1000 -exec chown 2000:2000 '{}' \+"

to change ownership of the files from user uid 1000 to uid 2000 : gid 2000 (replace the numbers with your desired numbers).

It is fairly obvious that with a small amount of Unix lore, this administration task can be successfully completed. The instructions can be made even more specific, if needed. It is specific to Unix (Linux), and will only ever be needed by someone running NFS in a networked environment (or, possibly, running a license server). In other words, in an office/work environment by an experienced admin, or by a small fraction of home users (a very small fraction).

Is it worth making a button for this? I think the answer is NO. I wouldn't even know where to look for such a thing -- it would take more instructions on how to use it, as compared to "cut and paste into a terminal".

There is common stuff that I would find trivial under Unix (Linux) that I would have no idea how to approach under Windows.

Not CRITICAL stuff; just "nice to have". When I run across one, I just give my head a shake, and ignore it. I expect that you are the same with Linux.

The people who should be or are using Linux know why. I can't advocate change just for change. There must be some benefit.

It may be hardware support. It may be POSIX compliance. It may be performance related. It may be something completely different.

For example -- with 2 and 3TB consumer drives available, I usually recommend a scrubbing, redundant file system. Like ZFS. Of course, that requires Solaris, Linux, BSD or MAC OS X (and it was removed from OS X). Linux has more hardware support, so it would be the choice. At least for the file server. Or, use BSD for a home NAS.

A reason to use Unix!

Talk with the users. Find out what they are after. You can even sell them a service. I wouldn't transition "Joe or Josephine Random" from Microsoft Windows to Unix (Linux, BSD, Apple) without a discussion.

Sure

rpm --root
yum history rollback
yum history redo
yum downgrade
rpm -V (may be debsums?)
yum versionlock
yum --enablerepo --disablerepo
rpm --docfiles --configfiles
rpm/yum reporting is nicer

Only two commands rpm underneath and yum on top.

The GP tore a hole out of yum/rpm vs apt/deb. As you point out there really isn't much daylight between. Except that (as a non-administrator having to do occasional admin tasks) I find rpm superior.

First, yum is superior technically to debians packaging system. Not going to bother explaining, because I seriously doubt it would do any good.

Next, this idea of rebooting (technically, two boots - download updates, reboot into a small system, apply updates, reboot into complete environment) is an idea that won't matter much soon.

Hard drives are already in the 3TB territory. btrfs or zfs will become necessary for reliability. When this happens, snapshots will be available to solve the problem properly.

Now, why Redhat recommends re-install? Redhat really only sells servers. Best practice is to re-install to verify that nothing has been forgotten during an upgrade. This applies whether its AIX, Redhat, Solaris or even Windows.

Fedora? Supports preupgrade. Just updated from F16 to F17 with that. Note that /bin is now only symlinks to /usr/bin; a major filesystem layout change was included.

It just worked (originally installed from a Fedora XFCE live CD spin).

robots.txt is a hint file to automated software crawling websites.

Note that everything on a web site is published.

Possibly not indexed, but, for an individual, robots.txt is just as valid an index as index.html.

So, the company published the information; the hacker group now has the information.

It wasn't theft -- the company still has the information.

The hacker group now told the company about this information. Actually, this should have been known by the company. Given that the company did not want to pay for suppressing republication, we can assume that they were aware.

The information accessed was a simple data list. Since this is pure information, it cannot be copyrighted.

So, republishing this information is not copyright infringement.

A simple offer was made -- please pay us not to republish the information. This is a normal legal offer. No law would be broken by republishing, and the information was not obtained illegally. It may have been worth something to republish, or (as the government has shown by paying farmers not to grow crops) it may have been worth something to not republish.

Given that the company should have aware of the availability of the information, we must assume that they wouldn't mind the republishing.

The hacker group would wish to remain anonymous. I imagine that the people on the list may like to sue someone, and may try to sue the hacker group. Making this more difficult makes sense. (Especially if the hacker group is not US resident).

This is not illegal access, extortion, copyright infringement or any other crime that I can think of. You may not like it. Heck, I don't like arbitrage.

It appears from your comment (focussing on the header) that you believe there is a difference between moral and legal here (Sophocles' tragedy Antigone comes to mind). As Plato exposes, you may want to work to bring your morality and law closer.

Be careful. Steps in that direction may bring the downfall of the Web (certainly the concept of URLs).

The hacker group has it right. They simply demanded a fee for stupidity. I don't believe that you can legislate stupidity out of existence.

"Let's see the open source keep up with the GL spec instead of holding the whole damn platform back in 2.0 land"

Normally, I wouldn't bother responding, because there is little chance that you will see this response. However, the above quote is important.

I will refer you to [Blythe2011] http://www.cs.cmu.edu/afs/cs/academic/class/15869-f11/www/lectures/blythe_compute.pdf

for an interesting critique on current 3D work.

And remember, the "radeon" driver supports R100 on up.

The AMD community supports all (11 now?) chip types, over all (4 now?) generations of Radeon released (since 2000).

KMS (kernel mode setting) and other features of the Linux graphics stack are supported over all hardware, including TV out, and other features.

3D is a work in progress. Yes, it's been almost five years, but the features do work.

I would say that, objectively, the open source drivers have been a success. I would even say that the open source drivers are arguably superior to the closed ones. Work continues (especially in the 3D area). Does the proprietary driver support stuff like multi-seat?

Of course, you claim that it doesn't work at all, and that the effort has been for nought. Please clarify. Bug reports would probably be welcome (not sure, but check x.org, freedesktop.org).

At the least, please post your hardware information, so that other people will know to avoid it.

You are very right.

May I recommend Paul Grahams "On Lisp"?

Use of functional programming, and macros to build dsm's reduces the code you need to write, and can simplify things.

You then need good ffi (foreign function interfacing) to utilize external libraries.

My favorite system (currently) is Gambit-C Scheme. It supports define-macro as well as hygenic macros. It compiles to C, so the ffi is simply writing "in-line" C code if needed. Best of all is it has a 20 year history behind it.

Some Ramblings

I have an NVidia (something or other) in my company assigned Dell Laptop.

Works a treat with the open driver. No 3D, but so be it. I don't game anyway.

The AMD/ATI situation? Same thing. Just takes time and effort to get the driver to the point where it can be even REMOTELY considered ready for the kernel.

The "driver du jour" from the hardware vendors? Can't be trusted.

Sure, if you are building your Supreme Gaming Machine, go for it. For any real work? Not so much.

Now, it gets weird. Because I am about to backpedal on that statement.

In some very limited circumstances, the vendor drivers may be deployed. Specifically, for GPU calculations. I still wouldn't trust these drivers in the role of a DISPLAY driver yet.

(I consider the GPU calculation testing to be more comprehensive and useful, although I find the use of OpenCL to be.. abhorrent).

But the set of features implemented by these drivers for 3D rendering (OpenGL) tends to be oriented towards gaming, and not the kind of visualizations needed for "real work". For example, 3D depth cued lines. A feature handily supported by SGI and SUN in the past, but missing from NVidia, ATI and Matrox the last time I looked -- 10 years ago, but I suspect still missing. Not that the feature was available in Mesa, either, but Mesa is the LOWEST level of support expected.

I would be happy if I were wrong, but, as far as I can see, Intel graphics is just as good (or bad) for my 3D visualization needs.

Now, I do have to give a tip of the hat to NVidia. They (at least) tried to support OpenGL with their implementation. But, I really don't understand how NVidia managed to create an OpenGL implementation that was arguably inferior to the SGI and SUN implementations. Possibly (and I speculate) that their attention was split by DirectDraw, and the perceived need to micro-optimize. The second reason was the need to replace a good deal of the driver stack, which NVidia tried to do without the cooperation of the kernel developers.

Which brings us to the present day, and a question: "What to do now"? Is it too late to have NVidia assist in laying out the driver stack? Most likely. The only beneficiary of the current situation is Intel. Intel has participated in laying out the ground work for display on Linux. Intel will reap the rewards of this. Both NVidia and AMD will be relegated to providing GPU processing, but will be squeezed from the bottom. After all, Intel will control the GPU sharing protocols. OpenCL will probably continue to entrench, and NVidia is trying to keep their compiler presence (they own the space right now). Intel is likely to release more general compilers and infrastructure to squeeze them.

AMD? I am afraid for them. They deserve better than to become a footnote in this saga.