It seems despite past tensions between Wietse Venema and Daniel J. Bernstein (the author of qmail), they agree on the approach to solving spam. Bernstein proposed a similar system called Internet Mail 2000 (Wikipedia entry).
You are right in what you said, except for one thing: multiplying a string by an integer in Python is a legal operation. The result is the string repeated X times, or the empty string when the integer is less or equal to zero.
Or the "International Organization of No Microsofts".
Bill G.: But you let in Johny Microsoft Ltd. Johny M.: [pops head out window] Hyuck hyuck! IONM: We said no Microsoft_s_. We're allowed to have one. Bill G.: Oh...
Those rules are to be followed by advertisers, not Google itself. Google, as the owner of the adwords service, can do pretty much whatever they want with their own service. Besides, I was simply warning about the technical capability they will have. I'm not saying they are using it or anything. As I said before, I sincerely hope they stay away from that kind of behaviour.
I've read the article at Linux Watch but I haven't read the PDF copy of the complaint, so I may be completely wrong. That said, BusyBox is a program that, as far as I know, is standalone. For example, Slackware uses BusyBox in the initrd you create with mkinitrd. The end result is a static binary called/bin/busybox that has links made to it, like/bin/ls -> busybox. BusyBox implements a lot of commands (they call them applets), and you can either call it as "busybox ls -l" or, if ls is a link to busybox, you can call it as "ls -l" directly and it will run the ls applet. So I am not sure how you can infringe the GPL with that. If they distribute something that contains BusyBox it could be considered a mere aggregation (as in "we need to run a bourne shell script so we distribute the script we wrote together with busybox and busybox runs the script"). But maybe they distribute a modified BusyBox.
Anyone willing to give more details about where the legal problem is? Thanks in advance.
persistent data in flash is only available to the domain that stored it. In other words, if a flash app that you downloaded from www.yousuck.com saves data, it cannot be read by a flash app you download from www.noseriouslyyousuck.com. So the truth is, flash is better for you in terms of privacy than are standard browser cookies.
Browser cookies also work this way in most cases. Remember that option saying "Only accept cookies from originating server"? Flash "cookies" work like that. They are not better, as you suggest. They are the same.
But wait (you're probably thinking) if google is serving every ad, then the domain is always google and google can then track where you're going!!
Exactly. The URL for an ad depends on the ad. Google may be serving all the ads from its domain, yet the ad URL could let Google perfectly track the site you are visiting.
That's true, and also irrelevant. If google is serving every ad then guess what, google can just look in their webserver logs for your IP address. So flash does nothing for them.
Hahahaha! Don't make me laugh. Flash does nothing? Let's check what they can do that their webserver logs can't do... first, it lets them track you from sites you visit without accessing from their websearch. Second, they can know which sites you actually visit. Third, they don't have to depend on your IP address. They can know who you are by storing a unique identifier like they did with the infamouse Google cookie that lasted until year 2038. And that identifier crosses IP addresses. Better yet, when you clean your browser cookies, a potential flash cookie isn't deleted. Better yet, if you change browsers and the flash plugin is installed in all of them, the cookie crosses browsers.
This is not FUD. This is something that _may_ be done. I only wonder if they will start doing that. I hope not, but I'm not spreading FUD. This is a pure technical capability available _now_. They _can_ use it if they _want_.
It would be interesting to see if they start storing a "flash cookie" (not really a cookie) to track your movements on the web. More information on the flash cookie here. Sorry to link my own blog. Text here if you don't want to click:
Yesterday I found out something quite interesting while reading a thread at LinuxQuestions.org. Summary: the flash browser plugin lets flash applications store information persistently on your hard drive. Sorry if this is common knowledge, but I didnt know it and Im quite shocked. That information can (may or may not) be used as browser cookies, as the thread shows. These days many people take their cookies seriously, maybe disabling them or deleting them from time to time or adjusting the browser cookie settings so it considers every cookie a session cookie that should be deleted when the browser is closed. Now, you need to be aware of a new battle front. Under Linux (and probably other Unix systems), these pieces of information are stored under $HOME/.macromedia/. Run find ~/.macromedia -print to get an overview.
I remember one of the reasons people started to care about cookies in the first place was that sites like doubleclick (recently bought by Google) would serve ads for thousands of websites on the net, and those ads would store a cookie in your hard drive identifying you, so they could in theory track what you visited on the net and build a profile. Today the problem would still exist because sometimes ads are served in flash format.
You can, however, configure the flash plugin so it doesnt let anybody store anything in your hard drive. It must be noted that to do so you must visit macromedia.com and adjust the plugin settings from a flash application that is available on their site. Moreover, if you completely disable data storage, you are warned that some sites may stop working. Amazing. So this problem is hard to avoid. My personal recommendation is to use a browser plugin like the typical FlashBlock for Firefox or the Load plugins on demand setting under Konqueror, so every flash application is blocked unless you specify otherwise. And, you may want to delete the $HOME/.macromedia/ directory from time to time, or at least part of its contents (settings are also stored in that directory). Its also worth mentioning that the settings and data are cross-browser, obviously. They are stored by the flash plugins no matter what browser youre running the plugin from.
Its a shame so many websites require flash for basic browsing, as well as the lack of a flash plugin for many platforms. The plugin could also have an option to delete any hard drive data when closing it, similar to the option to treat all cookies as session cookies that many browsers feature.
It is insulting that you say that, and you deserve being modded down. I started learning Python with the official tutorial, which is completely clear and exposes you all the language features in an afternoon. There is also a module index that contains the documentation for the different modules, exposing the objects, functions and constants from every module, as well as a list of modules. There's the library reference, that exposes all the modules (again, grouped by topic), all the built-in functions, data types and operations, etc. There is also a document describing the syntax in detail. There is also a document explaining how to embed and extend Python. Complain about its syntax, the way it does some things. Whatever you like to whine about. However, the Python documentation is excellent. No discussion allowed, coward.
I'm not trying to debunk your claims or anything, but I tried to reproduce that behaviour in my 2.6.22.6 kernel (no CFS, that will be in 2.6.23), and I couldn't make mplayer drop any frames. I launched mplayer to play an MPEG4 movie with MP3 audio, launched 8 infinite loops and ran updatedb so as to keep a good amount of IO too. mplayer didn't drop any frames and the audio didn't skip at all. The load average was 10 point something. And I set the scheduler governor to powersave, so I was effectively running at 800 MHz instead of the full 1800 Mhz.
Maybe my setup is different. Preemptive kernel, 1000 Hz, CFS IO scheduler. So I'm not sure how a load average of 2 or 4 can disturb the Linux kernel at all. Can you please elaborate on your setup? Maybe it's a bug in artsd or your video player. I have no idea. My mplayer uses ALSA.
My laptop came with a Broadcom 4318 chipset. The support for it is flacky and it only seems to work properly using ndiswrapper. Some days ago I decided I was going to try to buy a USB wifi device that was compatible with Linux. If possible, its drivers had to be already part of the vanilla kernel. To my surprise, those devices exist! They are the ones that have the ZyDas zd1211(b) chipset (the "b" one is better). I thought it was going to be hard to find one of those specific devices, but no. They are present in a wide range of USB wifi devices. I went to the two main malls in my country they had one of those devices each. Piece of cake. Furthermore, a USB dongle can be used in future computers very easily, and don't take power unless they're plugged in.
You only need the device, a vanilla kernel and firmware, which can be downloaded from SourceForge.net, and it's also probably available for your distribution as an official package.
No, sorry if that was confusing. I meant to say that KDE4 is a generic name for KDE 4.x, the whole release series (or branch, if you prefer). When the KDE developers talked about everything KDE4 will have, some people were left thinking that all the promised features will be in the KDE 4.0 release, and this is not the case. They should not think the KDE4 developers have lied and in the end left out all those features. KDE 4.0 will have all (or most) the underlying technologies needed to deliver the promised features, but some features will not appear inmediately. Instead, you may have to wait until KDE 4.1 (or 4.2, or...) to enjoy them.
The KDE developers have been reminding people that KDE4 is not KDE 4.0. KDE 4.0 will be the first release in the KDE4 series. All the promised features won't be there in the initial version, and some of them will have to wait until KDE 4.1 or KDE 4.2. It never hurts to remind this, for all the people who have very high expectations.
Re:Bad programmers need more than 80 columns
on
Are 80 Columns Enough?
·
· Score: 1, Troll
Repeating what I said on comment #19783713, it gets very ridiculous when you have several of those function calls split into 5 lines each. Is it very important to see which is the Nth argument in the list of arguments for a standard function call? I don't think so. The call to std::transform() is trivial. I don't have any special interest in knowing what I used as the third argument. What you gain horizontally you lose it vertically. 4 calls like that one and you have 20 lines.
In that specific case let's suppose the function has an initialization part, an if/else block and some terminating statements to return a result. With a long line that fits your screen, maybe you are able to put the whole function in a single screen. Let's say 5 initialization lines, 5 in the if part, 5 in the else part and 5 in the terminating part. 20 lines that fit in my screen. You can't do that if you split every call to std::transform into 5 lines. If the long line reads:
sol = ((-b) + sqrt((b * b) - (4.0 * a * c))) / (a + a);
Yes, you better split it to avoid making mistakes with parens and make it more readable:
sqrt_disc = sqrt((b * b) - (4.0 * a * c)); sol = ((-b) + sqrt_disc) / (a + a);
But split a call to std::transform() because it uses more than 80 lines? No way. I prefer to keep that trivial long line and be able to see the function structure at a glance. Short lines don't translate directly to better or more readable code.
Why must everything be on one line? We don't expect sentences to fit in one line.
It's silly to compare a source code file with a natural language text file. They're not the same case. They don't have the same structure and they are not formatted in the same way.
Notwithstanding the crapitude that is C++
I will ignore that flame...
You need to read past the greater crapitude that is slashcode. Pretend the 2nd and 3rd lines there line up under "left_operands.begin...".
And that's why I said that you end up with ridiculous situations. That line was one alone. Now, let's suppose you have 3 of those lines (or more) in the if block. You end up with 9 unreadable lines. All those parameters in a narrow column trying not to surpass column 80 because you simply don't want to surpass it. Oh, Lord, my code is so much better because I didn't use more than 80 columns... It's ridiculous. It does not make your code better. Is that code bad simply because it takes more than 80 columns? Hello, no. Not to mention that you lose visibility of the code below, which makes it harder to see when the if block ends, etc. I repeat my original point: You can't use column 80 to decide which code is good or bad. In some languages it can be a a symptom of too many nested blocks or too complicated operations. In some other languages it means nothing if you surpass it. It depends on the language.
I think it depends on the programming language. For C it's true that 80 columns should be enough. If you go much further, you may want to use auxiliar functions and such. However, in C++ and other languages, 80 columns is just not enough. By using two indentation levels (let's suppose an if block inside a function), you can easily get over 80 columns. There are some pieces of code that look ridiculous just because you're trying to limit them to 80 characters. For example, many standard library functions take 5 or more arguments. Just look at std::transform(), for example. It has a 5 arguments variant.
That line, which is pretty trivial and understandable for any C++ programmer, is already 130 characters long if you put a couple of tabs in front of it. If your terminal can display that in one single line, it's natural that you want to use only one line, because it should be read as a single operation, and you want to put one operation per line.
First off, excuse me if I'm going a bit off-topic here. While the Slackware team was preparing version 12.0 I worked on a new package/update manager for Slackware, called SlackRoll. I can't think of a better place to mention it than the Slackware 12.0 announcement thread in Slashdot, because it's probably going to be read by hundreds if not thousands of Slackware users.
One of the defining points of Slackware is the small set of official packages it features. On top of that, the native package management tools don't track depencencies and don't have the notion of remote repositories. All together, this doesn't adapt very well to users who want to try new software all the time and spend their days installing and removing packages. Doing that is hard with a vanilla Slackware, so people have created tools like swaret or slapt-get to simplify the process and be able to use remote repositories like the one at linuxpackages.net and similar, where they can download many unofficial packages that sometimes include dependency information slapt-get can use. I don't think that's "right". Let me explain. It's cool that Slackware is flexible enough to let you do that, but your system ends up in a very chaotic state after some time, in my experience (specially if you use slackware-current instead of slackware-stable). You can manage your system that way if you want, and maybe you're careful enough to do it, but it's very hard. That type of users would probably be happier with Arch, Gentoo or even Debian (I never understood the rivalry between Slackware and Debian; I've used both and both are great in their styles).
Patrick Volkerding probably thinks that way too, because he doesn't include those tools in Slackware. If I recall correctly, swaret was included for some time but in the end it was removed. He includes, however, a tool called slackpkg, which is clearly targetted at more "classic" Slackware users, because it lets you use one official mirror and manage systems composed of official packages for the most part, and includes some mechanisms to let you have some custom packages without being a headache (maybe downloaded from linuxpakages.net or slacky.eu or built with your own slackbuild scripts that you can also download from sites like slackbuilds.org). The problem is that slackpkg is slow (it's a big shell script), and doesn't let you track many corner events that happen frequently in slackware-current, so that's the starting point of slackroll.
Think of it like slackpkg on steroids. I specifically designed it to detect situations which are frequent in slackware-current, but it can also be used for slackware-stable without any problems. By design, it can:
Detect packages being added to the remote tree.
Detect upgrades and reverts.
Detect packages being deleted from the remote tree.
Give you the chance of choosing which package version to install if there are several available (main, extra, testing, etc).
Be told which packages are not official.
Detect when an unofficial package gets an official version.
Detect when a package with a custom build is removed from the remote tree.
And more stuff. Like I said, slackpkg on steroids. It's much faster, uses less bandwidth, detects more events and it's probably more flexible. I'm pretty satisfied with the result, so I wanted to invite people to read the program's webpage and try it if you think you fall into the target audience. It would be fine if I was the only user, but more eyes mean less bugs and I think it's always a shame when you create a tool which you are proud of and SourceForge only shows 20 downloads because people do not actually know it exists. Its main problem is that the initial setup may be more complex than usual and you need to read a bit more to know how it works. Howev
None of those three activities you mention need active wait really. For example, waiting for a process to finish is a matter of running wait() or waitpid(), which blocks until the process finishes. Waiting for a signal can be done by setting a signal handler and running pause(), for example, or by blocking the signal and running sigwait(). Waiting for other input (like in standard input) is also a blocking procedure. All those activities can be handled without waking up every second. If you have to do several of them at the same time you could simply use threads.
Thanks for the info. That's what I had found on Google, but it's not clear to me what KDE uses it for. I don't think that type of application needs to wake up once per second.
I have just tried the thing. I achieved less than 20 wakeups per second when my KDE desktop is idle, but learned a few things on the way. For example, by using a USB mouse instead of the laptop touchpad I am unable to reach state C3. It's reached when I unplug the mouse. I suppose I'll have to put up with it, because I can't stand the touchpad. On the other hand, I used to have KMail opened in a second virtual desktop to check for mail every 60 seconds, but I discovered that the bastard was waking up twice a second for no apparent reason, so I have started to use Korn (the mail check systray thingy). There are still some applications that wake up for no reason apparently. For example, why does klipper wake up once per second? And the same goes for kwrapper. I don't even know what that is. Can somebody explain in detail? Google isn't very specific about it.
But yes, the application is very interesting. Sorry, Intel, my laptop has an AMD processor. The next one will be Intel, with an Intel graphics card and an Intel wireless card. I promise.:P
If I recall correctly, adding a new device id to a driver is not acceptable for a stable release. There was a discussion not too long ago because, as you may know, there is someone maintaining a stable version of the 2.6.16 kernel. The maintainer added one device id in a driver, just like you suggested to do, and was told off for that.
The rationale is that in theory this can cause a working system to fail or be misconfigured after a kernel upgrade (due to a new device appearing in the system). That type of fixes are not accepted in stable kernels. If the current stable kernel is 2.6.X.Y, that type of patch should and will probably be held until 2.6.(X+1), and won't be included in 2.6.X.(Y+1). That's the standard vanilla kernel policy. Of course, Gentoo may have their own policies and may indeed apply the patch in their next kernel.
But vanilla kernel developpers only consider a patch for 2.6.X.(Y+1) valid if it fixes a real problem and it can be "guaranteed" that if your system worked with 2.6.X.Y, it will work if you blindly upgrade to 2.6.X.(Y+1).
I don't fully disagree with you. Renting content at a lower price may or may not work, but in the mean time Blockbuster closed all their stores in Spain because they were not profitable. So it's not a clear answer. Of course, they blamed piracy, but maybe people are no longer interested enough in renting movies and watching them at home when you can either watch them in the cinema or when they reach digital TV (and then you can record them). They are passed on digital TV maybe one or two months after they're available for rent. Maybe people think "well, I didn't watch it in the cinema 4 months ago, so why not wait 1 or 2 more months and I can watch it on TV?".
Slashdot Mirror
No, that was Unladen Swallow.
No, with two security holes. :)
"My Linux Annoyances as a Hardended Windows user"
It seems despite past tensions between Wietse Venema and Daniel J. Bernstein (the author of qmail), they agree on the approach to solving spam. Bernstein proposed a similar system called Internet Mail 2000 (Wikipedia entry).
You are right in what you said, except for one thing: multiplying a string by an integer in Python is a legal operation. The result is the string repeated X times, or the empty string when the integer is less or equal to zero.
Or the "International Organization of No Microsofts".
Bill G.: But you let in Johny Microsoft Ltd.
Johny M.: [pops head out window] Hyuck hyuck!
IONM: We said no Microsoft_s_. We're allowed to have one.
Bill G.: Oh...
Those rules are to be followed by advertisers, not Google itself. Google, as the owner of the adwords service, can do pretty much whatever they want with their own service. Besides, I was simply warning about the technical capability they will have. I'm not saying they are using it or anything. As I said before, I sincerely hope they stay away from that kind of behaviour.
Doh. So it's just a matter of putting a copy of the BusyBox source tarball they're using on their servers and providing a link?
I've read the article at Linux Watch but I haven't read the PDF copy of the complaint, so I may be completely wrong. That said, BusyBox is a program that, as far as I know, is standalone. For example, Slackware uses BusyBox in the initrd you create with mkinitrd. The end result is a static binary called /bin/busybox that has links made to it, like /bin/ls -> busybox. BusyBox implements a lot of commands (they call them applets), and you can either call it as "busybox ls -l" or, if ls is a link to busybox, you can call it as "ls -l" directly and it will run the ls applet. So I am not sure how you can infringe the GPL with that. If they distribute something that contains BusyBox it could be considered a mere aggregation (as in "we need to run a bourne shell script so we distribute the script we wrote together with busybox and busybox runs the script"). But maybe they distribute a modified BusyBox.
Anyone willing to give more details about where the legal problem is? Thanks in advance.
This is not FUD. This is something that _may_ be done. I only wonder if they will start doing that. I hope not, but I'm not spreading FUD. This is a pure technical capability available _now_. They _can_ use it if they _want_.
It is insulting that you say that, and you deserve being modded down. I started learning Python with the official tutorial, which is completely clear and exposes you all the language features in an afternoon. There is also a module index that contains the documentation for the different modules, exposing the objects, functions and constants from every module, as well as a list of modules. There's the library reference, that exposes all the modules (again, grouped by topic), all the built-in functions, data types and operations, etc. There is also a document describing the syntax in detail. There is also a document explaining how to embed and extend Python. Complain about its syntax, the way it does some things. Whatever you like to whine about. However, the Python documentation is excellent. No discussion allowed, coward.
http://www.python.org/doc/
I'm not trying to debunk your claims or anything, but I tried to reproduce that behaviour in my 2.6.22.6 kernel (no CFS, that will be in 2.6.23), and I couldn't make mplayer drop any frames. I launched mplayer to play an MPEG4 movie with MP3 audio, launched 8 infinite loops and ran updatedb so as to keep a good amount of IO too. mplayer didn't drop any frames and the audio didn't skip at all. The load average was 10 point something. And I set the scheduler governor to powersave, so I was effectively running at 800 MHz instead of the full 1800 Mhz.
Maybe my setup is different. Preemptive kernel, 1000 Hz, CFS IO scheduler. So I'm not sure how a load average of 2 or 4 can disturb the Linux kernel at all. Can you please elaborate on your setup? Maybe it's a bug in artsd or your video player. I have no idea. My mplayer uses ALSA.
My laptop came with a Broadcom 4318 chipset. The support for it is flacky and it only seems to work properly using ndiswrapper. Some days ago I decided I was going to try to buy a USB wifi device that was compatible with Linux. If possible, its drivers had to be already part of the vanilla kernel. To my surprise, those devices exist! They are the ones that have the ZyDas zd1211(b) chipset (the "b" one is better). I thought it was going to be hard to find one of those specific devices, but no. They are present in a wide range of USB wifi devices. I went to the two main malls in my country they had one of those devices each. Piece of cake. Furthermore, a USB dongle can be used in future computers very easily, and don't take power unless they're plugged in.
http://linuxwireless.org/en/users/Drivers/zd1211rw/devices
You only need the device, a vanilla kernel and firmware, which can be downloaded from SourceForge.net, and it's also probably available for your distribution as an official package.
http://sourceforge.net/project/showfiles.php?group_id=129083&package_id=187875
No, sorry if that was confusing. I meant to say that KDE4 is a generic name for KDE 4.x, the whole release series (or branch, if you prefer). When the KDE developers talked about everything KDE4 will have, some people were left thinking that all the promised features will be in the KDE 4.0 release, and this is not the case. They should not think the KDE4 developers have lied and in the end left out all those features. KDE 4.0 will have all (or most) the underlying technologies needed to deliver the promised features, but some features will not appear inmediately. Instead, you may have to wait until KDE 4.1 (or 4.2, or ...) to enjoy them.
The KDE developers have been reminding people that KDE4 is not KDE 4.0. KDE 4.0 will be the first release in the KDE4 series. All the promised features won't be there in the initial version, and some of them will have to wait until KDE 4.1 or KDE 4.2. It never hurts to remind this, for all the people who have very high expectations.
Repeating what I said on comment #19783713, it gets very ridiculous when you have several of those function calls split into 5 lines each. Is it very important to see which is the Nth argument in the list of arguments for a standard function call? I don't think so. The call to std::transform() is trivial. I don't have any special interest in knowing what I used as the third argument. What you gain horizontally you lose it vertically. 4 calls like that one and you have 20 lines.
In that specific case let's suppose the function has an initialization part, an if/else block and some terminating statements to return a result. With a long line that fits your screen, maybe you are able to put the whole function in a single screen. Let's say 5 initialization lines, 5 in the if part, 5 in the else part and 5 in the terminating part. 20 lines that fit in my screen. You can't do that if you split every call to std::transform into 5 lines. If the long line reads:
sol = ((-b) + sqrt((b * b) - (4.0 * a * c))) / (a + a);
Yes, you better split it to avoid making mistakes with parens and make it more readable:
sqrt_disc = sqrt((b * b) - (4.0 * a * c));
sol = ((-b) + sqrt_disc) / (a + a);
But split a call to std::transform() because it uses more than 80 lines? No way. I prefer to keep that trivial long line and be able to see the function structure at a glance. Short lines don't translate directly to better or more readable code.
It's silly to compare a source code file with a natural language text file. They're not the same case. They don't have the same structure and they are not formatted in the same way.
I will ignore that flame...
And that's why I said that you end up with ridiculous situations. That line was one alone. Now, let's suppose you have 3 of those lines (or more) in the if block. You end up with 9 unreadable lines. All those parameters in a narrow column trying not to surpass column 80 because you simply don't want to surpass it. Oh, Lord, my code is so much better because I didn't use more than 80 columns... It's ridiculous. It does not make your code better. Is that code bad simply because it takes more than 80 columns? Hello, no. Not to mention that you lose visibility of the code below, which makes it harder to see when the if block ends, etc. I repeat my original point: You can't use column 80 to decide which code is good or bad. In some languages it can be a a symptom of too many nested blocks or too complicated operations. In some other languages it means nothing if you surpass it. It depends on the language.
I think it depends on the programming language. For C it's true that 80 columns should be enough. If you go much further, you may want to use auxiliar functions and such. However, in C++ and other languages, 80 columns is just not enough. By using two indentation levels (let's suppose an if block inside a function), you can easily get over 80 columns. There are some pieces of code that look ridiculous just because you're trying to limit them to 80 characters. For example, many standard library functions take 5 or more arguments. Just look at std::transform(), for example. It has a 5 arguments variant.
std::transform(left_operands.begin(), left_operands.end(), right_operands.begin(), back_insert_iterator(result), binary_func());
That line, which is pretty trivial and understandable for any C++ programmer, is already 130 characters long if you put a couple of tabs in front of it. If your terminal can display that in one single line, it's natural that you want to use only one line, because it should be read as a single operation, and you want to put one operation per line.
One of the defining points of Slackware is the small set of official packages it features. On top of that, the native package management tools don't track depencencies and don't have the notion of remote repositories. All together, this doesn't adapt very well to users who want to try new software all the time and spend their days installing and removing packages. Doing that is hard with a vanilla Slackware, so people have created tools like swaret or slapt-get to simplify the process and be able to use remote repositories like the one at linuxpackages.net and similar, where they can download many unofficial packages that sometimes include dependency information slapt-get can use. I don't think that's "right". Let me explain. It's cool that Slackware is flexible enough to let you do that, but your system ends up in a very chaotic state after some time, in my experience (specially if you use slackware-current instead of slackware-stable). You can manage your system that way if you want, and maybe you're careful enough to do it, but it's very hard. That type of users would probably be happier with Arch, Gentoo or even Debian (I never understood the rivalry between Slackware and Debian; I've used both and both are great in their styles).
Patrick Volkerding probably thinks that way too, because he doesn't include those tools in Slackware. If I recall correctly, swaret was included for some time but in the end it was removed. He includes, however, a tool called slackpkg, which is clearly targetted at more "classic" Slackware users, because it lets you use one official mirror and manage systems composed of official packages for the most part, and includes some mechanisms to let you have some custom packages without being a headache (maybe downloaded from linuxpakages.net or slacky.eu or built with your own slackbuild scripts that you can also download from sites like slackbuilds.org). The problem is that slackpkg is slow (it's a big shell script), and doesn't let you track many corner events that happen frequently in slackware-current, so that's the starting point of slackroll.
Think of it like slackpkg on steroids. I specifically designed it to detect situations which are frequent in slackware-current, but it can also be used for slackware-stable without any problems. By design, it can:
And more stuff. Like I said, slackpkg on steroids. It's much faster, uses less bandwidth, detects more events and it's probably more flexible. I'm pretty satisfied with the result, so I wanted to invite people to read the program's webpage and try it if you think you fall into the target audience. It would be fine if I was the only user, but more eyes mean less bugs and I think it's always a shame when you create a tool which you are proud of and SourceForge only shows 20 downloads because people do not actually know it exists. Its main problem is that the initial setup may be more complex than usual and you need to read a bit more to know how it works. Howev
None of those three activities you mention need active wait really. For example, waiting for a process to finish is a matter of running wait() or waitpid(), which blocks until the process finishes. Waiting for a signal can be done by setting a signal handler and running pause(), for example, or by blocking the signal and running sigwait(). Waiting for other input (like in standard input) is also a blocking procedure. All those activities can be handled without waking up every second. If you have to do several of them at the same time you could simply use threads.
Thanks for the info. That's what I had found on Google, but it's not clear to me what KDE uses it for. I don't think that type of application needs to wake up once per second.
I have just tried the thing. I achieved less than 20 wakeups per second when my KDE desktop is idle, but learned a few things on the way. For example, by using a USB mouse instead of the laptop touchpad I am unable to reach state C3. It's reached when I unplug the mouse. I suppose I'll have to put up with it, because I can't stand the touchpad. On the other hand, I used to have KMail opened in a second virtual desktop to check for mail every 60 seconds, but I discovered that the bastard was waking up twice a second for no apparent reason, so I have started to use Korn (the mail check systray thingy). There are still some applications that wake up for no reason apparently. For example, why does klipper wake up once per second? And the same goes for kwrapper. I don't even know what that is. Can somebody explain in detail? Google isn't very specific about it.
:P
But yes, the application is very interesting. Sorry, Intel, my laptop has an AMD processor. The next one will be Intel, with an Intel graphics card and an Intel wireless card. I promise.
If I recall correctly, adding a new device id to a driver is not acceptable for a stable release. There was a discussion not too long ago because, as you may know, there is someone maintaining a stable version of the 2.6.16 kernel. The maintainer added one device id in a driver, just like you suggested to do, and was told off for that.
The rationale is that in theory this can cause a working system to fail or be misconfigured after a kernel upgrade (due to a new device appearing in the system). That type of fixes are not accepted in stable kernels. If the current stable kernel is 2.6.X.Y, that type of patch should and will probably be held until 2.6.(X+1), and won't be included in 2.6.X.(Y+1). That's the standard vanilla kernel policy. Of course, Gentoo may have their own policies and may indeed apply the patch in their next kernel.
But vanilla kernel developpers only consider a patch for 2.6.X.(Y+1) valid if it fixes a real problem and it can be "guaranteed" that if your system worked with 2.6.X.Y, it will work if you blindly upgrade to 2.6.X.(Y+1).
I don't fully disagree with you. Renting content at a lower price may or may not work, but in the mean time Blockbuster closed all their stores in Spain because they were not profitable. So it's not a clear answer. Of course, they blamed piracy, but maybe people are no longer interested enough in renting movies and watching them at home when you can either watch them in the cinema or when they reach digital TV (and then you can record them). They are passed on digital TV maybe one or two months after they're available for rent. Maybe people think "well, I didn't watch it in the cinema 4 months ago, so why not wait 1 or 2 more months and I can watch it on TV?".