FYI, we're not dealing with "the occasional bomb threat" here.
The University of Pittsburgh (which is down the street from where I work) has gotten multiple bomb threats per day every day for weeks now.
Many students have been driven out of their dorms, to live off campus, because the evacuations were too disruptive.
...
I agree that this situation stinks, and that obviously constantly evacuating buildings is very disruptive. However at the same time, can't the University of Pittsburgh and the Pittsburg police stop doing that and ignore the bomb threats, knowing that their leg is being pulled? I realize that there may be some legal precident why they can't... but at some point logic and common sense, along with the knowlege of "The boy who cried wolf" should also come into play.:-/
When I was in junior high school, one of the teachers I had in 8th grade at the time showed us the movie "A Clockwork Orange" on video, in its entirety, and then we had a discussion about it. In the film there's a scene where a well-endowed woman is fully nude and a number of males are preparing to gang rape her, but are interrupted by the main characters of the film, who then get into an all-out brawl.
As far as I know, none of we students complained, nor the parents. I felt that the movie was a bit shocking (duh) to show to JHS students, but that alone doesn't make it wrong to do so. If anything perhaps seeing it with adult supervision in such a setting might be fitting, because at least that way there's an adult to ask questions from or disscuss imagry that a student finds disturbing.
The other thought I had is that perhaps a book has more impact than a movie "because the pictures are better" -- i.e. the imagination can make imagry that can have more impact than any visual imagry can. Regardless of this, I see no reason why reading "Enders Game" to students should cause such a stir like this.
How about when customers sing the copyrighted song?:/
This occasionally happens when the customer brings their own celebration cake. Customers singing the standard "happy birthday" song in my experience is tolerated and nobody says anything about the song being "non-free" to sing with the standard lyrics. i.e. who gets to choose and sing the song and lyrics seems to go with who brings the cake.
I wish it weren't true, but sadly it is. This is why in the U.S. when you are given a "birthday cake" by a restaraunt, the waitresses cannot sing the standard "happy birthday" song and instead have to make up their own tune and their own lyrics, which don't invoke the same feelings that the standard song would have if they were allowed to sing it. This is an area of copyrights that I find invasive and counterproducitve.
What Ravi did was punch in the nose wrong - not 10 years in prison and deportation.
A jury of 12 people disagrees with your assessment.
Well, it's slightly different: the jury came to an agreement that what Ravi did met the criteria for the charges he was given. The jury doesn't get to decide how long Ravi spends in jail based on matching those charges -- that's for the judge alone to decide AFAIK. So the bottom line is the jury gets asked "did Ravi's behavior meet the following criteria", they say "yes", the judge then says "based on that I decree you get X years."
On this subject I think you've moved from "discussing" this with me to "talking at" me. You're telling me that reinstallation is "the right thing to do", regardless of my good reasons as to why I don't do that. I accept that you and I are in different paradigms in terms of system administration, and that as such we're not ever going to agree on this.
Well, I am telling me that your good reasons seem to me to boil down to some sort of wierd emotional thing.
? No.
I wrote a longer reply with some serious answers to your queries, but looking back starting right here I just can't take you seriously, so I'm just deleting it.
One piece of good news is that some systems erase/tmp on startup. Debian does this, for one.
Yes and no... Debian (and most other systems, I might add) only deletes the files/dirs that are still present on the filesystem (i.e. what "find" can find on/tmp). It doesn't try to securely wipe those data blocks or the data blocks that wasn't part of any of those files.
Damn good point. I stand corrected.
The last part is important, cause in the case of libvte, the file is open()'ed, then unlink()'ed right away, thereby no longer showing up on the filesystem even though the file is still in-use. The close() won't happen until the terminal is closed. In other words: As the file is no longer present on the filesystem, it won't be deleted (again) from/tmp and the data blocks won't be wipe. Therefore the old data will still be present on the disk even after a reboot.
I think you're right.:-/
You could probably change the boot script to use a more secure wipe of the files it's deleting, but that still won't help you in this case as the file in question was already delete long before the reboot. A complete wipe of/tmp's device won't be a good idea either, unless you're absolutely sure/tmp is on its own device, i.e. if/tmp is just an ordinary dir on/, you don't want to wipe all of / on boot up.
I suppose one option would be a "secure wipe on free space" via the sfill command from the secure-delete package on the filesystem that/tmp is mounted on.
IIRC at some point certain filesystems had a flag to set for a "secure delete" option, which would fill files erased with zeros when a file link count reached zero, but I don't recall whether any of these were actually implemented.
Very much in agreement, but in some instances there are additional features that further mitigate this at least in the long-term.
With cleartext from encrypted sessions hitting disk, this means that data could be sitting around in unused block in/tmp for years, so once you get rooted you have to assume everything ever done on other machines using a terminal on that machine has been exposed.
One piece of good news is that some systems erase/tmp on startup. Debian does this, for one. But also last I knew, other systems don't. Someone had reported about a year ago that Fedora didn't do this, for instance. It came up because the poor guy was using a Debian-based box and had copied his entire home directory into/tmp, rebooted, and expected to copy it back. Oops. That got into discussion of which systems erased/tmp and which didn't.
Additionally I've found that some newer Linux kernels in the 3.x series (at least 3.2) seem to mount/tmp as a tiny tmpfs filesystem, rather than using the root filesystem. [I've checked, and this is not something done in/etc/fstab. There's a tiny chance this might be something done via the initrd image, though.] tmpfs is still backed by swap, however.
"They will be allowed to choose their own distro," don't do that, it's going to be a nightmare.
From what I've seen, "They will be allowed to choose their own distro" is a necessity, because if a user has grown to love a particular distro and wants to use it, forcing them to use something else is going to change how they work. For instance, for the last couple of days here on Slashdot I've been discussing with user Arker the merits of Debian's upgrade-in-place methodology, verses Slackware's "wipe and reinstall" upgrade methology. He's convinced that "wipe and reinstall" is always the right answer, I'm convicned that "upgrade in place" is the right answer, and I can tell we're never going to agree. Distributions come with at least some form of paradigm that comes with them, and I think that needs to be taken into account.
So I think the OP has the right idea in giving the developers their choice of what to run.
I have a multi-pronged opinion on this; I at least agree in spirit.
I agree with you on the SysV part but I think that, at least at first, package management should be avoided. I think it's important for people to understand what's going on behind the package management, i.e. configuring and make-ing everything, make targets, etc. I started with Slackware too, and learned a great deal of knowledge that I wouldn't have if I had started with RedHat / Gentoo / Ubuntoo.
And yes, I realize that you can build your own from source on any of those, but with Slackware you're somewhat more forced to.
When it comes to people who are experimenters and who want to understand the system, I agree -- it's a good learning experience. When it comes to being a maintainer of a system for an "appliance operator", after knowing how to do it building from source is mainly an impediment. When it comes to an "appliance operator" just wanting something simple to install and use on their own, it's a barrier.
Back when I ran Slackware in the mid-late 90's, it was very typical for people to build their own Linux kernel. I still do that today on Debian and build it directly to a Debian package. But how many Linux users do this today? Not many, because it's genearally unnecessary -- and sad as that might be, most would say that's a good thing(tm). You can look at this as if people are ignorant for not knowing how to do this, or you can look at it as good that they don't have to know.
Being that the original poster is in a company of embedded hardware developers, Slackware might be a fitting choice. However it depends on their targets -- like for instance if what they ultimately want is to be able to target major distributions (which I doubt they are or the question wouldn't have come up), then that would change the picture.
I personally consider reinstalling from scratch a waste of my time, and even insulting for this is the standard upgrade method for a distribution.
I dont understand where this visceral aversion to reinstallation comes from, but I can understand that with it given you would be much happier with Debian.
But given that it's not that tough to do, quite easy to automate, doesnt need to be done very often and always works perfectly it seems like the best way to do things to me.
On this subject I think you've moved from "discussing" this with me to "talking at" me. You're telling me that reinstallation is "the right thing to do", regardless of my good reasons as to why I don't do that. I accept that you and I are in different paradigms in terms of system administration, and that as such we're not ever going to agree on this.
As long as you're in a position where that's easy, that's fine. However I manage a bunch of remote machines that I still need to upgrade, and reinstalling them from scratch is not something easy for me to do. Nor is it easy for someone that needs to upgrade lots of machines, or machines where there has been a lot of custom software installed, which I mentioned earlier.
In a case like that I would want to use an image-based system anyway. That works the same way regardless of distro.
That's a bit too vague for me to know specifically what you mean. Let's say I have a remote machine out in a bunker in California that I can only get to via ssh over the 'net -- and try to give me an idea of how I'd upgrade/reinstall Slackware.
Using 'checkinstall' as root may be workable for some, but basic functionality like that shouldnt require root, and it falls under the category of 'doing things in a needlessly complicated way just to be different' to my eye.
And no, contra your expressed certainty you can compile and install libraries to your hearts content under slack and it just works, as it should. (Standard caveats of course, assuming you arent doing something insanely stupid and wrong.)
I'm sure you can't install system libraries on Slackware without root privileges either.
You can build software on Debian just like you can on Slackware. root and 'checkinstall' are not a requirement.
'checkinstall' is simply a convenience to be able to install software and have it registered with the Debian package management system. Anything regarding the Debian package management system requires root. One of the good reasons to do this is if you install a custom version of something that Debian would normally have a package for that has a possibility of overwriting your installation. For instance if you custom compile a version of-- oh, Apache2 let's say -- and install that in/usr/sbin/apache2, you'd like it if Debian would complain and refuse to overwrite it if someone walks over and tries to install a different version Apache2 from the Debian repository. Or another reason is if you want to be able to easily remove the program you've custom compiled and installed -- 'checkinstall' watches the "make install" operation and tells Debian the list of files associated with the installation, so the package manager can remove those files if you remove the package. I'm sure the package manager in Slackware requires root too.
I will, however, admit that the two systems seem to have a different "feeling" somehow. Slackware somehow felt more "custom software friendly" in a way that's not easy to explain. It's not that you can't do these things on Debian, because you can, but the difference in paradigm to one of package management on Debian (or other systems) tends to dissuade software compilation a bit in favor of packages that can be upgraded and maintained that way. Overall this saves the operator a lot of work so I think it's a good thing, but in other way it does take away a
tell them to turn off the Strigi searching in the "Desktop Search" in System Settings
Is that something that's still there in KDE 4.7?
Yes it is. And it's now now even part of Trinity, I.E. the new incarnation of KDE 3. http://trinitydesktop.org/
I thought that KDE4 had improved in its latest iterations.
It has, but it still defaults to having Nepomuk and Strigi both being on and set to index everything in your home directory by default, and storing them in an SQL database using Virtuoso. This ends up taking up about 10% of the space you're currently using in your home directory in the database at ~/.kde/share/apps/nepomuk/repository/main/data/virtuosobackend/soprano-virtuoso.db Then, of course, by defualt it also wants to run MySQL server for Akonadi for storing and index and cache as part of PIM management and store that in ~/.local/share/akonadi/ somewhere, and wants to run another MySQL server process per user that's logged in, too. So if you use "Switch user" and log in as another user, you'll see two copies of MySQL server running -- and it's still like that with KDE 4.7.4.
There's a lot to like in KDE 4 today, but there are still things about it like this that I think are just wrong. Another example: if you right-click on an application in the menu, you can easily add it to the "Favorites" menu, an there are some there by default too. But how do you get something OUT of the Favorites? Well, you just do web searches to find out that you need to edit the text file ~/.kde/share/config/kickoffrc and edit the Favorites list manually. Another: print something, then try to figure out how to see the printer spool in KDE 4. Oops. You need to know to install "printer-applet", and even if you do it's not up to the job; you're better of logging directly into cups via the web interface at http://localhost:631/ than you are with using KDE 4's tools.
KDE 4 still isn't the well-oiled-machine that KDE 3 was. It's nice, it's comfortable, it's even slick, but it's still got some rough edges.
Despite Debian's policy of separating the source-available software from the binary-only software, RMS still doesn't endorse them as free. I think that Debian too is distancing itself from the FSF - they're not making their software GPL3 - particularly illustrated by their working on their version of clang. While it's true that they're working on Hurd, they're also working on kFreeBSD. So essentially, they'd have 3 platforms for their users, all of which hopefully would support apt packages. In fact, coming to think of it, that's the other advantage of supporting Debian.
AFAIK Debian makes its software available via GPLv3 where possible, and there have a clear policy that everything that is packaged needs to be very clear as to what license that software (or even files within the software or documentation) are under. I see Debian trying to work with the FSF where it can, and they had a FSF speaker at Debconf10 in NYC. The Debian develers are very devoted to the principles of software freedom. I have a lot of respect for RMS and historically he's been proven right time and time again, so regardless of often being looked upon as an extremist, he seems to have good forward-looking vision, and I think the Debian developers likewise take him seriously.
I'll have a look at what's going on with Clang, but in the meantime I shoud point out that packages in Debian usually start out being uploaded by an indiviual (possibly directly if the person is a Debian developer, or via a sponsored upload if the person is not a DD the the Debian Maintainers list). In the case of a sponsored upload, the amount of developer discussion and review may be relatively minimal, so I wouldn't look upon a single package in Debian as something to use to make a generalization about the entire distribution.
A minor, comment, about backups, don't forget/etc The amount of customizations and admin generated files in there can be huge, and time consuming to recreate.
Yes, agreed. And usually for more important configs I also incorporate revision control via Git.
I accept what you say, however last I used Slack (circa 2000) the method to upgrade Slackware was to wipe and reinstall with the new version. Put that together with a lot of manual software installation typical at the time of./configure, make, make install (because Slackware mainly only contained a base system), and it's a big headache to upgrade.
It is the preferred method to upgrade any OS if you ask me. The debian upgrade-in-place functionality is drop-dead easy and very rarely fails, but the failures tend to be spectacular.
The one issue with Debian upgrades between major versions is that you're not supposed to do the normal "apt-get upgrade", but rahter "apt-get dist-upgrade". If you don't know to do that, then yes, there's a chance of a spectacular upgrade failure. dist-upgrade knows the order that packages have to be upgraded in when changing major distribution versions, and the normal upgrade doesn't -- this is the major issue some users run into.
The only real issue I've personally ever run into in major upgrades is running out of disk space and having to do the upgrade in pieces. The other was making a big mistake in choosing what to install or upgrade due to user error, but all of that is correctable. Or, at least if I have had other problems, it's so long ago now (> 10 years) that I've forgotten what they may have been. But one thing I do remember is that no matter what has ever gone wrong with a Debian box I've had, I've always been able to rescue it and get it back to a working condition without ever having to do a reinstall on it.
I believe all the other issues I've heard people run into being package specific, such as issues upgrading MySQL relating to it having to do a one-way migration of the SQL databases. That can be a bit tricky if that goes wrong for some reason.
Wiping and reinstalling is and should be drop-dead easy as well, and never, ever fails. So you can see why I still prefer to stick to it.
If your partitions are setup correctly you can wipe the system and reinstall to your hearts content without touching user data, so why is it such a problem?
As long as you're in a position where that's easy, that's fine. However I manage a bunch of remote machines that I still need to upgrade, and reinstalling them from scratch is not something easy for me to do. Nor is it easy for someone that needs to upgrade lots of machines, or machines where there has been a lot of custom software installed, which I mentioned earlier. And besides all of that, being that I already have a system that lets me upgrade in place, I personally consider reinstalling from scratch a waste of my time, and even insulting for this is the standard upgrade method for a distribution.
Of course you want to make a backup first, but I would be much more worried about doing that before I let apt take over.
I always have backups of the user data, and the package list, because that's all I need. For upgrades I'm really concerned about (like upgrading remote servers) I occasionally create a VM in either VirtualBox or KVM to duplicate the box to test the upgrade first to I know everything to expect, mainly because configuration files sometimes change for services between the major upgrades and I want to know how those configs need to change to minimize the service impact.
Slackware's package management is brilliant. It uses straight tarballs, unpacks them and executes the scripts, period. It installs and removes software from the computer, and since it doesnt attempt to do everything else under the sun as well, you can count on it to do its job correctly. It's up to you, of course, to make sure that you install the correct.pkg. I have never seen it cause any sort of problem for anyone, the only complaint is that it doesnt do all t
As much as I agree with what you've said, I wouldn't recommend Slackware for teaching purposes because of it's BSD startup methology, because I found switching over to any other System V type startup with/etc/init.d/ scripts to be painful
That's very true, but I think you take the wrong lesson from it. SysV init is a monstrosity that should be killed with fire wherever it is found. Switching over to it is always painful, but apparently not as painful as it needs to be to keep people from using it, unfortunately.
I guess I have mixed feelings about this -- on the one hand I agree with you, however on the other I'm now very used to starting/stoping/restarting/checking_status_of services via typing "/etc/init.d/ [start|stop|restart|status]". So yes, SysV is a bit of an abomination, but there are certain nice features you get as an admin from using it.
That said, Slack does include a SysV init system (for compatibility with some stupid programs that assume it) and it's accessible so you could learn that on Slackware as well, if you want to.
Good to know. I'll try to find out more about that next time I play with Slackware again. [I check it out again periodically.]
Last I checked Slackware 13(something) didn't have an official package manager of any kind. The lack of package management back in the 1999 to 2000 timeframe is what forced me to switch distros to something that did
Slackware package system has always worked very well for me. It definitely does have an official package management system and it works wonderfully. On the other hand RPM and even DEB based systems have driven me back to Slack many times. I have lived through many horror stories with those systems - but installpkg has never failed me.
I accept what you say, however last I used Slack (circa 2000) the method to upgrade Slackware was to wipe and reinstall with the new version. Put that together with a lot of manual software installation typical at the time of./configure, make, make install (because Slackware mainly only contained a base system), and it's a big headache to upgrade.
When I went over to Debian, the method of upgrade is to modify/etc/apt/sources.list to swith to the new repository, then do "apt-get dist-upgrade", and the entire Debian system gets upgraded in place. This, combined with a very rich repository of software packages, meant that I no longer had to wipe and reinstall unless I wanted to for some reason, like changing filesystems or changing disks. And when I do reinstall, all I need is a package list via "dpkg --get-selections > filename" and I know what I need to install.
At least in 2000, the difference was night and day. Today there are more options for Slackware to keep it up-to-date, but last I checked they weren't "officially supported" by Slackware. That's what I meant when I said that Slackware "didn't have an official package manager".
I agree with you -- just tweaking with a small amount of aditional advice.
I use Ubuntu and TinyCore at work, and Debian with KDE at home.
I think the real issue is not the distro, so much, as desktop environment. Gnome is for people who really aren't too familiar with Linux, IMO. It hides much of the complexity/functionality to provide a simplified interface. KDE provides a lot more control, at the expense of simplicity.
Ironically, in the local LUG I belong to http://mhvlug.org/ the majority of the knowledgable people in the group use Ubuntu and Gnome, and I seem to be the only KDE user as well as the only Debian user. Even stranger, several core people in the group are switching to Unity. We're having a "Desktop Shootout" meeting this Wednesday (March 7), and the current Desktop Environments to be discussed are KDE, Unity, Cinnamon (Gnome2 shell on top of Gnome3, which is what Linux Mint 12 uses), and fvwm.
There's others, like Unity (which I despise).
Still with you there.;-)
I'm not conversant with most of them, so, unlike many of my brethren here, I'll refrain from commenting on them.
Of the two, I prefer KDE. I can set a system up the way I want it to work easily enough.
This is the point where I have a suggestion: when you tell others about KDE4, tell them to turn off the Strigi searching in the "Desktop Search" in System Settings. The 6+ background "nepomukservices" processes that start searching through the user's home directory make KDE4 immediately very sluggish and is what pushes a lot of people away from KDE4 and drop it as an option, because "it makes my computer run like shit." KDE4 is really a wonderful environment to work in, and I'd like to see more people be able to find that out and experience it for themselves without the burden Strigi puts on them by default.
At work we use Ubuntu/Gnome. I do not like it at all - clumsy in the way it handles multiple desktops, for one thing.
I haven't yet tried Gnome3... I should probably go do that. When I've had to use Gnome2 I was able to deal with it and found it at least usable.
That said, if you do want to go KDE, Ubuntu seems to be moving away from KDE, so you may not want to go Ubuntu.
Now, as to distro, Debian has a reputation for being stodgy, and never releasing anything in a timely manner. OTOH, their stable releases are rock solid. IIRC, Ubuntu has a direct relationship with Debian's unstable version.
Finally, I prefer Debian's attitude towards separating free as-in-beer software from free-as-in-speech software. It matters to me, it may not matter to you.
When it comes to Debian Stable I think everything above is correct.
However for Debian Sid, i.e. Debian Wheezy/Unstable, Debian "releases" new packages about every 4 hours. And when running "Debian Unstable", you get the power and support of Debian at the same time as getting something 6 months newer than Ubuntu. Hard to beat.;-) If you ever want to try running Debian Sid/Unstable sometime, I suggest adding the "apt-listbugs" package, which will warn you of impending doom at update/upgrade time if someone has filed a high severity bug on a package you're about to install.:-)
If you're trying to teach them to use Linux for general purposes, I'd go with Mint. It passes the Aunt Tilly test with flying colors in my experience
Because I kept getting people recommending Mint to those of us who were pissed off with Unity on Ubuntu, I gave it a try. I honestly don't understand what people like about it.
There are two distributions of Mint: "Linux Mint 12", based on Ubuntu, and "Linux Mint Debian" that's based on Debian. As a Debian user I tried Mint 12 and also didn't like it, then tried Mint Debian and was much happier with it. I normally use DuckDuckGo via SSL as my search of choice, so if Google wasn't an option by default, I probably wouldn't have noticed. I just double-checked, and Google was the default search engine in Iceweasel (which is Firefox renamed due to trademark action from Mozilla) in Mint Debian -- and DuckDuckGo isn't one of the default options. I'm okay with that.
If you're bringing people over from the Windows world, please encourage KDE. It's a pretty good take on the "taskbar w/ a start button" GUI-style and will be immediately familiar to most folks. One word of advice: "Classic Menu Style" for the launcher will help keep things much more traditional.
Agree with the above, with one addition: immediately explain how to turn of Strigi "Desktop Search" functionality, or the people using KDE are going to think that it sucks. Nepomuk/Strigi immediately wants to run 6+ background "ontologies" to search and index files in your home directory, which is such an I/O strain that on old computers it's hard to even operate the mouse on the screen.
Back then of course the two most common were Redhat and Slackware.
They used to say "If you run Redhat, you know Redhat. If you run Slackware, you know Linux"
There are no shortcuts with Slackware. The students can learn how and why. Then, once they get the base knowledge, they can move on to easier distros. I don't bother with endless tinkering anymore, I just don't have the time. But the knowledge I picked up when I had to still serves me well.
As much as I agree with what you've said, I wouldn't recommend Slackware for teaching purposes because of it's BSD startup methology, because I found switching over to any other System V type startup with/etc/init.d/ scripts to be painful. Last I checked Slackware 13(something) didn't have an official package manager of any kind. The lack of package management back in the 1999 to 2000 timeframe is what forced me to switch distros to something that did. Thankfully I went over to Debian, where I've been happy ever since. I do occasionally still miss Slackware, because it really was (and is) a nice distribution and I have a lot of respect for those that still run it.
However the newer versions of KDE4 are being based on Qt5, which has a base requirement of OpenGL (ES) 2.0 or above.
If I understood properly, the issue is that Qt5 will use an OpenGL rendering model. That doesn't mean that the graphics hardware requires an OpenGL working driver to function, because Qt5 can use a raster engine in the CPU, like does right now (passing "-graphicssystem raster", which is the default). Actually, they have given some numbers, and the CPU rasterizer is faster in Qt5, because LLVMpipe is faster than Qt's rasterizer.
That's really interesting, and it's good news. As long as Qt5 + KDE5 continue to allow machines to use it without requiring OpenGL 3D support in hardware, especially if there's still a software rendering (i.e. rasterizer) available, I'm happy. And I don't even need for it to be fast -- just that it will work. Thank you VERY much for pointing the above information out.
Remember also that Qt5 is not out yet, much less KDE5. It will take years for being forced to upgrade to KDE5. This year we will have a LTS release of Kubuntu, which means you will have supported KDE4 till April 2017. I think there will be also one or maybe even two Debian releases with KDE4.
That's good as a backup plan, although I'll doubt I'll need to resort to using it based on the technical details you've given me above. Debian has had KDE4 since the release of Squeeze two years ago. I've run Kubuntu in the past and ccasionally I retry Kubuntu (and Mint Debian) but haven't found any compelling reason to switch away from Debian, as Debian has full support for doing major upgrades without reinstallation. And as you probably know, Canonical recently announced that they were going to stop funding Kubuntu development after the April release of Kubuntu 12.04 and is also dropping commercial support for it.
Still a shame those gui's became so bloathed and slooowwww. And thank God for fluxbox and the likes.
If this is how you feel, then you'd use Kwin with effects off, and wouldn't care about lack of OpenGL compositing. So I don't see your point.
Temporarily, right now, that works. However the newer versions of KDE4 are being based on Qt5, which has a base requirement of OpenGL (ES) 2.0 or above. http://labs.qt.nokia.com/2011/05/09/thoughts-about-qt-5/ This means presumably KDE4 will have the same base requirement.:-/
The current "compilation requirements" are listed for KDE 4.4 but not for any version newer than that, but it is very likely that KDE4 will eventually have a baserequirement of OpenGL (ES) 2.0 due to that being a requirement for Qt5.
Even if the frequency ranges aren't the same, in the context of safety concerns, both of the above frequency ranges are in the same ballpark. Interestingly if you read the IEEE C95.1 report (which is difficult to get a copy of) you'll find that the most concervative levels of concern are somewhere around 5 to 10 W/m^2, and that includes a 10:1 safety margin of the actual power density levels of concern for controled invironments. [If you find the report, see Figures 3 and 4.] However if you want to understand RF exposure, a good place to start that is readily accessible is right at the FCC: http://transition.fcc.gov/oet/rfsafety/rf-faqs.html
Also for the Original Article to say that Electromagnetic Radiation hasn't been studied enough is dubious and at best a truism, because it's been studied for 60 years. America, Canada, Japan, and the EU all have their own studies and conconclusions about safe electromagnetic levels broken down by frequency ranges. The only known concern is RF heating, and WiFi can't put out enough power for that to be a concern. Cell base stations put out only a small amount of power per sector antenna (typically about 20 Watts) and these antennas have a "pancake" pattern that focuses at the horizon, so even standing right under the base station isn't unsafe. You have to be three feet in front of the base station antenna before it would be unsafe -- and for that to happen you'd have to be right in front of it on the tower. The cell phone right against the head is a lot stronger amount of RF exposure than a cell phone base station right across the street is.
There's a LOT of general misunderstanding of "RF exposure", which usually comes out as "we don't understand it enough" in some form. To an extent that may always be true, because it's something you can only measure with equipment and is otherwise invisible to a human being. So for some it's hard to understand that low levels of RF exposure is safe.
Slashdot Mirror
"Stand back... I'm going to try LOGIC..."
FYI, we're not dealing with "the occasional bomb threat" here.
The University of Pittsburgh (which is down the street from where I work) has gotten multiple bomb threats per day every day for weeks now.
Many students have been driven out of their dorms, to live off campus, because the evacuations were too disruptive.
...
I agree that this situation stinks, and that obviously constantly evacuating buildings is very disruptive. However at the same time, can't the University of Pittsburgh and the Pittsburg police stop doing that and ignore the bomb threats, knowing that their leg is being pulled? I realize that there may be some legal precident why they can't... but at some point logic and common sense, along with the knowlege of "The boy who cried wolf" should also come into play. :-/
This is rediculous.
When I was in junior high school, one of the teachers I had in 8th grade at the time showed us the movie "A Clockwork Orange" on video, in its entirety, and then we had a discussion about it. In the film there's a scene where a well-endowed woman is fully nude and a number of males are preparing to gang rape her, but are interrupted by the main characters of the film, who then get into an all-out brawl.
As far as I know, none of we students complained, nor the parents. I felt that the movie was a bit shocking (duh) to show to JHS students, but that alone doesn't make it wrong to do so. If anything perhaps seeing it with adult supervision in such a setting might be fitting, because at least that way there's an adult to ask questions from or disscuss imagry that a student finds disturbing.
The other thought I had is that perhaps a book has more impact than a movie "because the pictures are better" -- i.e. the imagination can make imagry that can have more impact than any visual imagry can. Regardless of this, I see no reason why reading "Enders Game" to students should cause such a stir like this.
How about when customers sing the copyrighted song? :/
This occasionally happens when the customer brings their own celebration cake. Customers singing the standard "happy birthday" song in my experience is tolerated and nobody says anything about the song being "non-free" to sing with the standard lyrics. i.e. who gets to choose and sing the song and lyrics seems to go with who brings the cake.
Hahaha. Nice idea. Thanks for the information. :-)
Yes, if anyone can hear you sing.
I wish it weren't true, but sadly it is. This is why in the U.S. when you are given a "birthday cake" by a restaraunt, the waitresses cannot sing the standard "happy birthday" song and instead have to make up their own tune and their own lyrics, which don't invoke the same feelings that the standard song would have if they were allowed to sing it. This is an area of copyrights that I find invasive and counterproducitve.
What Ravi did was punch in the nose wrong - not 10 years in prison and deportation.
A jury of 12 people disagrees with your assessment.
Well, it's slightly different: the jury came to an agreement that what Ravi did met the criteria for the charges he was given. The jury doesn't get to decide how long Ravi spends in jail based on matching those charges -- that's for the judge alone to decide AFAIK. So the bottom line is the jury gets asked "did Ravi's behavior meet the following criteria", they say "yes", the judge then says "based on that I decree you get X years."
Well, I am telling me that your good reasons seem to me to boil down to some sort of wierd emotional thing.
? No.
I wrote a longer reply with some serious answers to your queries, but looking back starting right here I just can't take you seriously, so I'm just deleting it.
One piece of good news is that some systems erase /tmp on startup. Debian does this, for one.
Yes and no... Debian (and most other systems, I might add) only deletes the files/dirs that are still present on the filesystem (i.e. what "find" can find on /tmp). It doesn't try to securely wipe those data blocks or the data blocks that wasn't part of any of those files.
Damn good point. I stand corrected.
The last part is important, cause in the case of libvte, the file is open()'ed, then unlink()'ed right away, thereby no longer showing up on the filesystem even though the file is still in-use. The close() won't happen until the terminal is closed. In other words: As the file is no longer present on the filesystem, it won't be deleted (again) from /tmp and the data blocks won't be wipe. Therefore the old data will still be present on the disk even after a reboot.
I think you're right. :-/
You could probably change the boot script to use a more secure wipe of the files it's deleting, but that still won't help you in this case as the file in question was already delete long before the reboot. A complete wipe of /tmp's device won't be a good idea either, unless you're absolutely sure /tmp is on its own device, i.e. if /tmp is just an ordinary dir on /, you don't want to wipe all of / on boot up.
I suppose one option would be a "secure wipe on free space" via the sfill command from the secure-delete package on the filesystem that /tmp is mounted on.
IIRC at some point certain filesystems had a flag to set for a "secure delete" option, which would fill files erased with zeros when a file link count reached zero, but I don't recall whether any of these were actually implemented.
Very much in agreement, but in some instances there are additional features that further mitigate this at least in the long-term.
With cleartext from encrypted sessions hitting disk, this means that data could be sitting around in unused block in /tmp for years, so once you get rooted you have to assume everything ever done on other machines using a terminal on that machine has been exposed.
One piece of good news is that some systems erase /tmp on startup. Debian does this, for one. But also last I knew, other systems don't. Someone had reported about a year ago that Fedora didn't do this, for instance. It came up because the poor guy was using a Debian-based box and had copied his entire home directory into /tmp, rebooted, and expected to copy it back. Oops. That got into discussion of which systems erased /tmp and which didn't.
Additionally I've found that some newer Linux kernels in the 3.x series (at least 3.2) seem to mount /tmp as a tiny tmpfs filesystem, rather than using the root filesystem. [I've checked, and this is not something done in /etc/fstab. There's a tiny chance this might be something done via the initrd image, though.] tmpfs is still backed by swap, however.
Great, now I'll have that Timberwolf tune stuck in my head for the next couple of days.
For all who don't know what I'm talking about:
http://frededison.free.fr/
or Thomas Timberwolf on youtube...
Hahah! Now I'm going to have that stuck in my head for the next couple of days. ;-)
But seriously, thanks -- nice link.
"They will be allowed to choose their own distro,"
don't do that, it's going to be a nightmare.
From what I've seen, "They will be allowed to choose their own distro" is a necessity, because if a user has grown to love a particular distro and wants to use it, forcing them to use something else is going to change how they work. For instance, for the last couple of days here on Slashdot I've been discussing with user Arker the merits of Debian's upgrade-in-place methodology, verses Slackware's "wipe and reinstall" upgrade methology. He's convinced that "wipe and reinstall" is always the right answer, I'm convicned that "upgrade in place" is the right answer, and I can tell we're never going to agree. Distributions come with at least some form of paradigm that comes with them, and I think that needs to be taken into account.
So I think the OP has the right idea in giving the developers their choice of what to run.
I have a multi-pronged opinion on this; I at least agree in spirit.
I agree with you on the SysV part but I think that, at least at first, package management should be avoided. I think it's important for people to understand what's going on behind the package management, i.e. configuring and make-ing everything, make targets, etc. I started with Slackware too, and learned a great deal of knowledge that I wouldn't have if I had started with RedHat / Gentoo / Ubuntoo.
And yes, I realize that you can build your own from source on any of those, but with Slackware you're somewhat more forced to.
When it comes to people who are experimenters and who want to understand the system, I agree -- it's a good learning experience. When it comes to being a maintainer of a system for an "appliance operator", after knowing how to do it building from source is mainly an impediment. When it comes to an "appliance operator" just wanting something simple to install and use on their own, it's a barrier.
Back when I ran Slackware in the mid-late 90's, it was very typical for people to build their own Linux kernel. I still do that today on Debian and build it directly to a Debian package. But how many Linux users do this today? Not many, because it's genearally unnecessary -- and sad as that might be, most would say that's a good thing(tm). You can look at this as if people are ignorant for not knowing how to do this, or you can look at it as good that they don't have to know.
Being that the original poster is in a company of embedded hardware developers, Slackware might be a fitting choice. However it depends on their targets -- like for instance if what they ultimately want is to be able to target major distributions (which I doubt they are or the question wouldn't have come up), then that would change the picture.
I dont understand where this visceral aversion to reinstallation comes from, but I can understand that with it given you would be much happier with Debian.
But given that it's not that tough to do, quite easy to automate, doesnt need to be done very often and always works perfectly it seems like the best way to do things to me.
On this subject I think you've moved from "discussing" this with me to "talking at" me. You're telling me that reinstallation is "the right thing to do", regardless of my good reasons as to why I don't do that. I accept that you and I are in different paradigms in terms of system administration, and that as such we're not ever going to agree on this.
In a case like that I would want to use an image-based system anyway. That works the same way regardless of distro.
That's a bit too vague for me to know specifically what you mean. Let's say I have a remote machine out in a bunker in California that I can only get to via ssh over the 'net -- and try to give me an idea of how I'd upgrade/reinstall Slackware.
Using 'checkinstall' as root may be workable for some, but basic functionality like that shouldnt require root, and it falls under the category of 'doing things in a needlessly complicated way just to be different' to my eye.
And no, contra your expressed certainty you can compile and install libraries to your hearts content under slack and it just works, as it should. (Standard caveats of course, assuming you arent doing something insanely stupid and wrong.)
I'm sure you can't install system libraries on Slackware without root privileges either.
You can build software on Debian just like you can on Slackware. root and 'checkinstall' are not a requirement.
'checkinstall' is simply a convenience to be able to install software and have it registered with the Debian package management system. Anything regarding the Debian package management system requires root. One of the good reasons to do this is if you install a custom version of something that Debian would normally have a package for that has a possibility of overwriting your installation. For instance if you custom compile a version of-- oh, Apache2 let's say -- and install that in /usr/sbin/apache2, you'd like it if Debian would complain and refuse to overwrite it if someone walks over and tries to install a different version Apache2 from the Debian repository. Or another reason is if you want to be able to easily remove the program you've custom compiled and installed -- 'checkinstall' watches the "make install" operation and tells Debian the list of files associated with the installation, so the package manager can remove those files if you remove the package. I'm sure the package manager in Slackware requires root too.
I will, however, admit that the two systems seem to have a different "feeling" somehow. Slackware somehow felt more "custom software friendly" in a way that's not easy to explain. It's not that you can't do these things on Debian, because you can, but the difference in paradigm to one of package management on Debian (or other systems) tends to dissuade software compilation a bit in favor of packages that can be upgraded and maintained that way. Overall this saves the operator a lot of work so I think it's a good thing, but in other way it does take away a
tell them to turn off the Strigi searching in the "Desktop Search" in System Settings
Is that something that's still there in KDE 4.7?
Yes it is. And it's now now even part of Trinity, I.E. the new incarnation of KDE 3. http://trinitydesktop.org/
I thought that KDE4 had improved in its latest iterations.
It has, but it still defaults to having Nepomuk and Strigi both being on and set to index everything in your home directory by default, and storing them in an SQL database using Virtuoso. This ends up taking up about 10% of the space you're currently using in your home directory in the database at ~/.kde/share/apps/nepomuk/repository/main/data/virtuosobackend/soprano-virtuoso.db Then, of course, by defualt it also wants to run MySQL server for Akonadi for storing and index and cache as part of PIM management and store that in ~/.local/share/akonadi/ somewhere, and wants to run another MySQL server process per user that's logged in, too. So if you use "Switch user" and log in as another user, you'll see two copies of MySQL server running -- and it's still like that with KDE 4.7.4.
There's a lot to like in KDE 4 today, but there are still things about it like this that I think are just wrong. Another example: if you right-click on an application in the menu, you can easily add it to the "Favorites" menu, an there are some there by default too. But how do you get something OUT of the Favorites? Well, you just do web searches to find out that you need to edit the text file ~/.kde/share/config/kickoffrc and edit the Favorites list manually. Another: print something, then try to figure out how to see the printer spool in KDE 4. Oops. You need to know to install "printer-applet", and even if you do it's not up to the job; you're better of logging directly into cups via the web interface at http://localhost:631/ than you are with using KDE 4's tools.
KDE 4 still isn't the well-oiled-machine that KDE 3 was. It's nice, it's comfortable, it's even slick, but it's still got some rough edges.
Despite Debian's policy of separating the source-available software from the binary-only software, RMS still doesn't endorse them as free. I think that Debian too is distancing itself from the FSF - they're not making their software GPL3 - particularly illustrated by their working on their version of clang. While it's true that they're working on Hurd, they're also working on kFreeBSD. So essentially, they'd have 3 platforms for their users, all of which hopefully would support apt packages. In fact, coming to think of it, that's the other advantage of supporting Debian.
AFAIK Debian makes its software available via GPLv3 where possible, and there have a clear policy that everything that is packaged needs to be very clear as to what license that software (or even files within the software or documentation) are under. I see Debian trying to work with the FSF where it can, and they had a FSF speaker at Debconf10 in NYC. The Debian develers are very devoted to the principles of software freedom. I have a lot of respect for RMS and historically he's been proven right time and time again, so regardless of often being looked upon as an extremist, he seems to have good forward-looking vision, and I think the Debian developers likewise take him seriously.
I'll have a look at what's going on with Clang, but in the meantime I shoud point out that packages in Debian usually start out being uploaded by an indiviual (possibly directly if the person is a Debian developer, or via a sponsored upload if the person is not a DD the the Debian Maintainers list). In the case of a sponsored upload, the amount of developer discussion and review may be relatively minimal, so I wouldn't look upon a single package in Debian as something to use to make a generalization about the entire distribution.
A minor, comment, about backups, don't forget /etc The amount of customizations and admin generated files in there can be huge, and time consuming to recreate.
Yes, agreed. And usually for more important configs I also incorporate revision control via Git.
It is the preferred method to upgrade any OS if you ask me. The debian upgrade-in-place functionality is drop-dead easy and very rarely fails, but the failures tend to be spectacular.
The one issue with Debian upgrades between major versions is that you're not supposed to do the normal "apt-get upgrade", but rahter "apt-get dist-upgrade". If you don't know to do that, then yes, there's a chance of a spectacular upgrade failure. dist-upgrade knows the order that packages have to be upgraded in when changing major distribution versions, and the normal upgrade doesn't -- this is the major issue some users run into.
The only real issue I've personally ever run into in major upgrades is running out of disk space and having to do the upgrade in pieces. The other was making a big mistake in choosing what to install or upgrade due to user error, but all of that is correctable. Or, at least if I have had other problems, it's so long ago now (> 10 years) that I've forgotten what they may have been. But one thing I do remember is that no matter what has ever gone wrong with a Debian box I've had, I've always been able to rescue it and get it back to a working condition without ever having to do a reinstall on it.
I believe all the other issues I've heard people run into being package specific, such as issues upgrading MySQL relating to it having to do a one-way migration of the SQL databases. That can be a bit tricky if that goes wrong for some reason.
Wiping and reinstalling is and should be drop-dead easy as well, and never, ever fails. So you can see why I still prefer to stick to it.
If your partitions are setup correctly you can wipe the system and reinstall to your hearts content without touching user data, so why is it such a problem?
As long as you're in a position where that's easy, that's fine. However I manage a bunch of remote machines that I still need to upgrade, and reinstalling them from scratch is not something easy for me to do. Nor is it easy for someone that needs to upgrade lots of machines, or machines where there has been a lot of custom software installed, which I mentioned earlier. And besides all of that, being that I already have a system that lets me upgrade in place, I personally consider reinstalling from scratch a waste of my time, and even insulting for this is the standard upgrade method for a distribution.
Of course you want to make a backup first, but I would be much more worried about doing that before I let apt take over.
I always have backups of the user data, and the package list, because that's all I need. For upgrades I'm really concerned about (like upgrading remote servers) I occasionally create a VM in either VirtualBox or KVM to duplicate the box to test the upgrade first to I know everything to expect, mainly because configuration files sometimes change for services between the major upgrades and I want to know how those configs need to change to minimize the service impact.
Slackware's package management is brilliant. It uses straight tarballs, unpacks them and executes the scripts, period. It installs and removes software from the computer, and since it doesnt attempt to do everything else under the sun as well, you can count on it to do its job correctly. It's up to you, of course, to make sure that you install the correct .pkg. I have never seen it cause any sort of problem for anyone, the only complaint is that it doesnt do all t
That's very true, but I think you take the wrong lesson from it. SysV init is a monstrosity that should be killed with fire wherever it is found.
Switching over to it is always painful, but apparently not as painful as it needs to be to keep people from using it, unfortunately.
I guess I have mixed feelings about this -- on the one hand I agree with you, however on the other I'm now very used to starting/stoping/restarting/checking_status_of services via typing "/etc/init.d/ [start|stop|restart|status]". So yes, SysV is a bit of an abomination, but there are certain nice features you get as an admin from using it.
That said, Slack does include a SysV init system (for compatibility with some stupid programs that assume it) and it's accessible so you could learn that on Slackware as well, if you want to.
Good to know. I'll try to find out more about that next time I play with Slackware again. [I check it out again periodically.]
Slackware package system has always worked very well for me. It definitely does have an official package management system and it works wonderfully. On the other hand RPM and even DEB based systems have driven me back to Slack many times. I have lived through many horror stories with those systems - but installpkg has never failed me.
I accept what you say, however last I used Slack (circa 2000) the method to upgrade Slackware was to wipe and reinstall with the new version. Put that together with a lot of manual software installation typical at the time of ./configure, make, make install (because Slackware mainly only contained a base system), and it's a big headache to upgrade.
When I went over to Debian, the method of upgrade is to modify /etc/apt/sources.list to swith to the new repository, then do "apt-get dist-upgrade", and the entire Debian system gets upgraded in place. This, combined with a very rich repository of software packages, meant that I no longer had to wipe and reinstall unless I wanted to for some reason, like changing filesystems or changing disks. And when I do reinstall, all I need is a package list via "dpkg --get-selections > filename" and I know what I need to install.
At least in 2000, the difference was night and day. Today there are more options for Slackware to keep it up-to-date, but last I checked they weren't "officially supported" by Slackware. That's what I meant when I said that Slackware "didn't have an official package manager".
I agree with you -- just tweaking with a small amount of aditional advice.
I use Ubuntu and TinyCore at work, and Debian with KDE at home.
I think the real issue is not the distro, so much, as desktop environment. Gnome is for people who really aren't too familiar with Linux, IMO. It hides much of the complexity/functionality to provide a simplified interface. KDE provides a lot more control, at the expense of simplicity.
Ironically, in the local LUG I belong to http://mhvlug.org/ the majority of the knowledgable people in the group use Ubuntu and Gnome, and I seem to be the only KDE user as well as the only Debian user. Even stranger, several core people in the group are switching to Unity. We're having a "Desktop Shootout" meeting this Wednesday (March 7), and the current Desktop Environments to be discussed are KDE, Unity, Cinnamon (Gnome2 shell on top of Gnome3, which is what Linux Mint 12 uses), and fvwm.
There's others, like Unity (which I despise).
Still with you there. ;-)
I'm not conversant with most of them, so, unlike many of my brethren here, I'll refrain from commenting on them.
Of the two, I prefer KDE. I can set a system up the way I want it to work easily enough.
This is the point where I have a suggestion: when you tell others about KDE4, tell them to turn off the Strigi searching in the "Desktop Search" in System Settings. The 6+ background "nepomukservices" processes that start searching through the user's home directory make KDE4 immediately very sluggish and is what pushes a lot of people away from KDE4 and drop it as an option, because "it makes my computer run like shit." KDE4 is really a wonderful environment to work in, and I'd like to see more people be able to find that out and experience it for themselves without the burden Strigi puts on them by default.
At work we use Ubuntu/Gnome. I do not like it at all - clumsy in the way it handles multiple desktops, for one thing.
I haven't yet tried Gnome3... I should probably go do that. When I've had to use Gnome2 I was able to deal with it and found it at least usable.
That said, if you do want to go KDE, Ubuntu seems to be moving away from KDE, so you may not want to go Ubuntu.
Now, as to distro, Debian has a reputation for being stodgy, and never releasing anything in a timely manner. OTOH, their stable releases are rock solid. IIRC, Ubuntu has a direct relationship with Debian's unstable version.
Finally, I prefer Debian's attitude towards separating free as-in-beer software from free-as-in-speech software. It matters to me, it may not matter to you.
When it comes to Debian Stable I think everything above is correct.
However for Debian Sid, i.e. Debian Wheezy/Unstable, Debian "releases" new packages about every 4 hours. And when running "Debian Unstable", you get the power and support of Debian at the same time as getting something 6 months newer than Ubuntu. Hard to beat. ;-) If you ever want to try running Debian Sid/Unstable sometime, I suggest adding the "apt-listbugs" package, which will warn you of impending doom at update/upgrade time if someone has filed a high severity bug on a package you're about to install. :-)
If you're trying to teach them to use Linux for general purposes, I'd go with Mint. It passes the Aunt Tilly test with flying colors in my experience
Because I kept getting people recommending Mint to those of us who were pissed off with Unity on Ubuntu, I gave it a try. I honestly don't understand what people like about it.
There are two distributions of Mint: "Linux Mint 12", based on Ubuntu, and "Linux Mint Debian" that's based on Debian. As a Debian user I tried Mint 12 and also didn't like it, then tried Mint Debian and was much happier with it. I normally use DuckDuckGo via SSL as my search of choice, so if Google wasn't an option by default, I probably wouldn't have noticed. I just double-checked, and Google was the default search engine in Iceweasel (which is Firefox renamed due to trademark action from Mozilla) in Mint Debian -- and DuckDuckGo isn't one of the default options. I'm okay with that.
If you're bringing people over from the Windows world, please encourage KDE. It's a pretty good take on the "taskbar w/ a start button" GUI-style and will be immediately familiar to most folks. One word of advice: "Classic Menu Style" for the launcher will help keep things much more traditional.
Agree with the above, with one addition: immediately explain how to turn of Strigi "Desktop Search" functionality, or the people using KDE are going to think that it sucks. Nepomuk/Strigi immediately wants to run 6+ background "ontologies" to search and index files in your home directory, which is such an I/O strain that on old computers it's hard to even operate the mouse on the screen.
Yes.
I cut my teeth on Slackware 3.5
I likewise started with Slackware 3(something).
Back then of course the two most common were Redhat and Slackware.
They used to say "If you run Redhat, you know Redhat. If you run Slackware, you know Linux"
There are no shortcuts with Slackware. The students can learn how and why. Then, once they get the base knowledge, they can move on to easier distros. I don't bother with endless tinkering anymore, I just don't have the time. But the knowledge I picked up when I had to still serves me well.
As much as I agree with what you've said, I wouldn't recommend Slackware for teaching purposes because of it's BSD startup methology, because I found switching over to any other System V type startup with /etc/init.d/ scripts to be painful. Last I checked Slackware 13(something) didn't have an official package manager of any kind. The lack of package management back in the 1999 to 2000 timeframe is what forced me to switch distros to something that did. Thankfully I went over to Debian, where I've been happy ever since. I do occasionally still miss Slackware, because it really was (and is) a nice distribution and I have a lot of respect for those that still run it.
Awesome post. :-)
However the newer versions of KDE4 are being based on Qt5, which has a base requirement of OpenGL (ES) 2.0 or above.
If I understood properly, the issue is that Qt5 will use an OpenGL rendering model. That doesn't mean that the graphics hardware requires an OpenGL working driver to function, because Qt5 can use a raster engine in the CPU, like does right now (passing "-graphicssystem raster", which is the default). Actually, they have given some numbers, and the CPU rasterizer is faster in Qt5, because LLVMpipe is faster than Qt's rasterizer.
That's really interesting, and it's good news. As long as Qt5 + KDE5 continue to allow machines to use it without requiring OpenGL 3D support in hardware, especially if there's still a software rendering (i.e. rasterizer) available, I'm happy. And I don't even need for it to be fast -- just that it will work. Thank you VERY much for pointing the above information out.
Remember also that Qt5 is not out yet, much less KDE5. It will take years for being forced to upgrade to KDE5. This year we will have a LTS release of Kubuntu, which means you will have supported KDE4 till April 2017. I think there will be also one or maybe even two Debian releases with KDE4.
That's good as a backup plan, although I'll doubt I'll need to resort to using it based on the technical details you've given me above. Debian has had KDE4 since the release of Squeeze two years ago. I've run Kubuntu in the past and ccasionally I retry Kubuntu (and Mint Debian) but haven't found any compelling reason to switch away from Debian, as Debian has full support for doing major upgrades without reinstallation. And as you probably know, Canonical recently announced that they were going to stop funding Kubuntu development after the April release of Kubuntu 12.04 and is also dropping commercial support for it.
http://www.omgubuntu.co.uk/2012/02/canonical-withdraw-financial-support-from-kubuntu/
http://www.h-online.com/open/news/item/Canonical-pulls-funding-from-Kubuntu-drops-commercial-support-1429603.html
Still a shame those gui's became so bloathed and slooowwww. And thank God for fluxbox and the likes.
If this is how you feel, then you'd use Kwin with effects off, and wouldn't care about lack of OpenGL compositing. So I don't see your point.
Temporarily, right now, that works. However the newer versions of KDE4 are being based on Qt5, which has a base requirement of OpenGL (ES) 2.0 or above. http://labs.qt.nokia.com/2011/05/09/thoughts-about-qt-5/ This means presumably KDE4 will have the same base requirement. :-/
No need to switch. KDE will work fine, you just won't have all the fancy effects you may have become accustomed to.
Don't make that pronouncement so fast; Qt5 has a requrement for OpenGL (ES) 2.0 or above, and KDE4 is now being developed using Qt5.
http://labs.qt.nokia.com/2011/05/09/thoughts-about-qt-5/
The current "compilation requirements" are listed for KDE 4.4 but not for any version newer than that, but it is very likely that KDE4 will eventually have a baserequirement of OpenGL (ES) 2.0 due to that being a requirement for Qt5.
http://techbase.kde.org/Schedules
>Yeah, same frequency as WiFi, dude
No it isn't.
WiFI 2.4GHz
DECT 1.9GHz
Even if the frequency ranges aren't the same, in the context of safety concerns, both of the above frequency ranges are in the same ballpark. Interestingly if you read the IEEE C95.1 report (which is difficult to get a copy of) you'll find that the most concervative levels of concern are somewhere around 5 to 10 W/m^2, and that includes a 10:1 safety margin of the actual power density levels of concern for controled invironments. [If you find the report, see Figures 3 and 4.] However if you want to understand RF exposure, a good place to start that is readily accessible is right at the FCC: http://transition.fcc.gov/oet/rfsafety/rf-faqs.html
Also for the Original Article to say that Electromagnetic Radiation hasn't been studied enough is dubious and at best a truism, because it's been studied for 60 years. America, Canada, Japan, and the EU all have their own studies and conconclusions about safe electromagnetic levels broken down by frequency ranges. The only known concern is RF heating, and WiFi can't put out enough power for that to be a concern. Cell base stations put out only a small amount of power per sector antenna (typically about 20 Watts) and these antennas have a "pancake" pattern that focuses at the horizon, so even standing right under the base station isn't unsafe. You have to be three feet in front of the base station antenna before it would be unsafe -- and for that to happen you'd have to be right in front of it on the tower. The cell phone right against the head is a lot stronger amount of RF exposure than a cell phone base station right across the street is.
There's a LOT of general misunderstanding of "RF exposure", which usually comes out as "we don't understand it enough" in some form. To an extent that may always be true, because it's something you can only measure with equipment and is otherwise invisible to a human being. So for some it's hard to understand that low levels of RF exposure is safe.