Not at all. They're not simple options either. Italic or not italic is easy to understand. And most options are irrelevant in most of the cases.
In comparison, mencoder offers options such as whether to perform post-processing with a chroma or luma deblocking or deringing filter.
I have only a vague understanding of what this does, and absolutely no clue what the result will look like without trying it. This option alone will need a few minutes of research or testing to understand it, and there are a couple hundred of that kind after you're done with it.
I will repeat my main point since you can't bother with the rest of the post: The problem with mencoder isn't the interface, it's to understand what the hell it does. If you understand what is chroma and luma, and what is a deblocking filter and why would you want one, then you shouldn't have a lot of problems coming up with the right set of arguments to mencoder. If you don't know, then having those options presented through a GUI isn't going to help you much.
I'm not even going to bother reading the rest of your post, it's obvious you've either never used a GUI app, or you're completely disinterested in an intellectually-honest discussion.
Sure I used a GUI app. I used many. I used Windows from 3.1 to XP, OS/2, OpenSolaris, and several Linux distros. Right now I'm typing this into Konqueror. I used various office apps, as well as Photoshop and 3D Studio for instance.
I don't rule GUIs out by any measure. In fact I do my coding in KDevelop, and have used Visual Studio quite a bit as well. Though I prefer by far prefer to use makefiles to do the build.
Well, if your GUI has 20 pages with 20 options on each page, then it was designed by a complete retard. The debate is whether a *good* GUI program is better than a CLI program. Obviously, a shitty GUI program will be worse, that's pretty much the definition of "shitty GUI program."
I've never seen a good GUI program with such a large amount of options.
The way I imagine this coming out is something similar to the project settings in an IDE. You have settings for the compiler, linker, paths, etc, and often 3-5 subsections inside each of those.
It doesn't matter how you cut it, 385 options is a lot of stuff to represent in a GUI. If you know of a program that does something of comparable complexity in an intuitive manner, I'd love to see it.
Why not? You can have rational presets
So you can in a CLI. For example the rsync "-a" option. There's no reason why mencoder couldn't take a --preset=dvd argument or something similar.
There's tons of potential for clarification in a GUI that doesn't exist in a CLI.
Point. But you can't clarify everything.
1) AppleScript rocked-ass in MacOS Classic. There's no reason CLI scripting *has* to be better than GUI scripting, you're just dealing with (repeat it with me:) a shitty GUI!
Maybe it did, never used it. But please come up with a modern example. A complete GUI for mencoder would be something that would have to run on modern systems.
1) There are GUIs that are used for batch processing work that are really, really, good. For example, Photoshop's batch processing options. Again, if you're used to shitty GUIs, you don't know these exist.
I said with no GUI installed. I have a Linode for instance. It's a virtualized Linux install. I guess I could run a GUI app on it anyway, but a remote GUI access across contienents would be rather painful and pointless. Much easier to let the server do the work then download the results.
By "batch processing" I mean a more automated operation btw, such as take file uploads by HTTP, put in a queue that might be internally distributed to several encoding servers, put the results somewhere.
2) You're also acting as if a GUI and CLI are mutually-exclusive. Stop doing that.
No, I'm not. I put the cdrecord and K3B example for instance. But in general, my servers don't have any GUI on them, so any app that requires one is out of the question.
Possibly it wouldn't make it easier for "normal people." But I doubt that. If the GUI was done well, it would make it easier for *everybody*, "normal" or not. Now you've gone into pretty much full condescension "everybody who prefers a GUI is a retard" mode. Stop doing that.
No, it's not about that. I repeat, mencoder is a low level tool. A GUI on it doesn't remove the need to understand video concepts such as PAL vs NTSC, interlacing, containers and codecs. Just like an IDE doesn't remove the need to understand programming.
An IDE may offer a window with checkboxes for optimization levels, and the help file may explain what inlining and loop unrolling do, but the manual isn't going to contain enough Computer Science information to fully understand the meanings of those options and whether they're going to benefit your program.
What I'm trying to say here is that understanding video is a much bigger problem than figuring out the UI. If you know what you need, then figuring out the required options shouldn't take very long. If you don't, then having the options represented with checkboxes isn't going to help much.
Let me quote an example from the mencoder manpage:
mbcmp=<0-2000>
Sets the comparison function for the macroblock decision, has only an effect if mbd=0.
That'd be the hell of a GUI. According to a quick check, mencoder has about 385 possible options. A GUI that presents all those options would be incredibly complex.
At that point, IMO, a CLI interface wins by far. Why?
1. In a GUI with 20 pages of configuration with 20 options on each it's very difficult to find the current configuration state. Meanwhile on the commandline it's obvious which of the 400 options are being used.
2. Regardless of how pretty you make it, the fact is that mencoder is a low level tool, which requires understanding video concepts to use effectively. A GUI for all its features isn't going to clarify things by much.
3. Scripts are easier in a CLI environment. Telling people to check this and that option is very tedious for something with such an amount of options, and following the instructions is equally bothersome. Plain text that can be copy/pasted is a lot more convenient.
4. Why put a GUI on a tool that can be used for batch processing work? What if somebody wants to encode videos on a server, with no GUI installed?
5. Who would use a full GUI adaption of mencoder anyway? It wouldn't make it much easier for normal people. Now a GUI with a more limited purpose, such as a GUI to transcode video to the format portable players want is a lot more limited in scope, needs much fewer options, and in fact has been done already.
6. This seems like a pointless discussion anyway, since we have the best of both worlds already. For those who want scriptability, there's mencoder. For those who want a GUI there are multiple frontends for it. It's the same as burning CDs, K3B is a frontent for cdrecord, and that seems to work just fine.
1. The daemon runs as an user with access to sudo (exploiting the apache account won't do) 2. sudo authorization is system-wide (not true on many distros) 3. The sudo config doesn't require it to run on a tty (actual daemons don't have one)
So in theory it's doable, in practice it won't work that well on decently configured systems. For instance, in Ubuntu sudo authorization is per console. For it to work well you'd have to trick the user to start the program on the same terminal sudo will be run on.
Further difficulties can be added with for example the grsecurity patch, making the user unable to execute programs from non-root owned directories.
This came up in a previous discussion. The SMM is simply a part of the normal RAM, used for the CPUs own purposes. While the OS can't normally touch it, it's still RAM and doesn't persist across reboots.
All that putting the virus into SMM RAM means is that as memory not normally accessible by the OS, so an antivirus can't go and scan it. But something has to put the virus into the SMM RAM anyway, and that something is on the hard disk or comes from an exploit through the network.
Yes, that's true. However, realtime priority without realtime patch is pretty damned non-realtime. Otherwise, we wouldn't need a realtime patch.
No, not really. Realtime priority and the -rt patch do different things.
Realtime priority ensures that the pulse daemon always comes first when it comes to CPU time. This ensures that it can't happen that for instance a CPU intensive process, like a game, gcc, povray, etc doesn't let the daemon have enough CPU time to do its mixing in time. In a conflict between pulseaudio and a game wanting CPU time, pulseaudio will always win, ensuring the audio doesn't skip at the cost of the game's performance.
The -rt patch, on the other hand, reduces kernel latency. By doing that it minimizes the time the daemon has to wait, and makes it possible to use a smaller buffer. If the kernel can take say, 100ms to give control back to user space in some cases, then you must have at least a 100ms audio buffer, and that means that any audio played will always be delayed by 100ms.
Well, why don't you go test it? In the meantime you can read more about the issue.
I tried this a few minutes ago. top shows this as "RT" so it indeed has realtime priority. The system remains perfectly responsive, and I had no problem using "top" to check its priority, or killing it.
I first tested this years ago when I got a dual Athlon MP. Initially I booted with only one CPU, then added the second. A very noticeable difference I found was that at the time I had a buggy artsd that locked up sometimes. With one CPU, the box locked up and I could go for a coffee. After a few minutes it finally died for some reason, making it possible to use again without a reboot. Once I installed the second CPU I reproduced the bug. And absolutely no problem this time, the system remained perfectly functional.
Note that the article you linked talks about CPU affinity. Processes aren't normally locked to a single CPU, and if they are, they're usually very specific ones, like important daemons. It makes very little sense to set affinity on for instance a terminal emulator, so even if a bad RT process kills your database performance, that still shouldn't stop you from fixing the problem.
Realtime priority means it's got priority over anything else in the system. If it wants to run, then everything else stops.
The realtime patch is a patch to reduce kernel latency, which is good for audio or a computer that needs to react consistently and quickly to external events. But it's not related to realtime priority.
If you've got at least a dual core CPU, a stuck RT process shouldn't bring the system down. It'll use up one core, but you'll still have another to kill it.
File names aren't really part of the problem here. It's trivial to set up a hash table to hide them.
Well, and what are you going to search by, then? The way I see it, the way to do this is to encrypt the content, but provide unencrypted, searchable metadata.
What I'm saying is that the metadata often contains plenty private data. People want to hide the fact they have porn at all. Making it so that a porn collection is searchable but not viewable doesn't really help much. Mails with titles like "My wife will come home late tomorrow, let's meet" contain enough suspicious data right there that hiding the text doesn't do much good.
There's plenty meaning that can be derived from just filenames.
Does it really matter that Google or whoever can't see the exact text or images, but has enough information from filenames, tags and descriptions to accurately find out what kind of furry porn you like?
People who encrypt their data often don't want to disclose even what kind of content they have. Knowledge of what sort of porn is there, or that you're having an affair, or private internal company data are things that can be disclosed from just knowing document titles without having to even look at the exact file.
The solution to this is to take Google out of the equation. Encrypt your computer's hard disk, encrypt all your mail, build your own search database that will be stored on the encrypted disk, and search that.
But that's not a correct answer in terms of the exercise, assuming the hole is accidental and not intended.
Which is what I'm getting at. In the sentence "select 1 from dual where 1 not in (2,3,NULL)", saying there's no 1 in a list of (2,3,NULL) would be incorrect.
Why? Because the NULL stands for "missing value" in this case, which indicates that *something* must be in this place, but for whatever reason the data isn't there. So we can't say with certainty that there's no 1 in that list.
It's like I can't say that I never had a coworker called Bob, because I didn't know the names of everybody working in the company.
Why not? The approach works fine on Mac OS X (even though I do lament the lack of a proper package manager).
IIRC, OS X has quite a few versions, and many apps require a particular version precisely for this reason: in exchange for not having a package manager and dependencies like Linux, they have to either ship everything or have the OS do it.
There are advantages and inconveniences to every approach.
What is/opt used for these days?
Self contained applications. Basically the whole/Programs idea.
Many distributions don't follow this
Is the distinction between/usr/ and/usr/local/ particularly important any more?
It's very important. Suppose that for you're a Perl coder, and for whatever reason you want to get the absolute latest development version installed, but system-wide (perhaps you're going to use it for web development). The distro won't give you the absolute latest Perl version because it's an important package: it might well stop booting if Perl gets screwed up. And if you built it yourself and installed over the the system version you might well have that problem. Then there would be the issue of how would the package manager deal with that.
So it goes in/usr/local/bin. It won't be used on boot, the package manager won't mess with it, and you can't mess anything up that way.
If you don't do this sort of thing,/usr/local is irrelevant. It should be completely empty on any system that doesn't have any packages brought in by "make; sudo make install".
Does it make sense for/var and/proc to be separated?
You seem to be confused./var is for permanent, but changing on-disk data./proc is an artifical, kernel generated virtual filesystem. It doesn't exist physically on disk, and doesn't retain changes across reboots. It can't be used to store arbitrary data. Things may appear and disappear depending on connected hardware and running processes.
Why do X11 apps need their own folder within/usr/?
There seems to be a general move away from this, moving X into/usr:
$ ls -l/usr/X11R6/ lrwxrwxrwx 1 root root 6 2009-01-04 21:28 bin ->../bin drwxr-xr-x 3 root root 4096 2009-01-04 21:33 lib
Note that lib is empty, and probably kept for some backwards compatibility reason.
Why is mail stored in/var instead of user folders?
/var/spool/mail is a deprecated mechanism on the principle that new mail goes into/var/spool/mail/$username. The user then reads that, cleans up the spool, and keeps or discards the mail. This is an old way of doing it.
Modern systems will not do that, and deliver to a Maildir in $HOME.
This isn't a fixed thing, a mail server can be configured to deliver mail in different ways. You can have/var/spool/mail, maildir in $HOME, procmail,.forward, and probably a delivery into a table in a database if you want.
/System/Settings/passwd is something to do with the system's settings, probably some system password file from the looks of it.
Or it just exactly as meaningless as/etc/passwd to somebody living in Russia or China, because they have no clue what "settings" or "password" mean.
Though why do they have to mess with that stuff anyway? If you're going to assume a stupid user who is going to think that/etc/passwd keeps web browser passwords and will try to delete it (how? modern friendly distros don't run as root, and won't allow that), you might as well go all the way, and pretend $HOME is/. Simply add an "user friendly mode" to the file browser in which it's locked inside $HOME, and/media is mapped to some place in $HOME, named according to the user's language settings.
Advantages: No internationalization issues, much less likely that an user will screw up system data by accident, doesn't matter how the directories are called and how they're structured.
Your arguments against this distro can be applied equally to all the others. RedHat has a different filesystem placement than Debian for example. Try installing via RPM on one machine and see where it ends up compared to apt-get on another.
True, but at least it's not completely different. Some things like the network settings are done differently on RH vs Debian, but the vast majority of stuff is either in the same place, or if not, in the immediate vicinity. For instance, some distros place SVN repositories in/var/svn and some in/var/lib/svn, but if you understand the organization you know it must be in/var, so that's at least a start of where to start looking.
Within the distro, there's consistency, but linux already lacks consistency between distributions. Gobo is no different.
Precisely, and we need more of it, not having each distribution come up with a new crazy scheme
How would/Applications vs/Programs be any different than/bin vs/usr/local/bin, other than it being more intuitive?
/Applications vs/Programs is a different choice of word for the same thing, while/bin and/usr/local/bin have different uses. The former is for binaries needed during boot, the later is optional binaries installed without a package manager. There's a very large difference between them:/bin is a system area, and/usr/local/bin is an admin controlled area the OS won't mess with. And no matter what you do, the box will still boot, because/usr/local isn't on the path while booting.
One final note: when you say 99% of users, you mean Linux users, who represent a pitiful percentage of overall OS users. Package managers, and the arcane filesystem will keep the figure near-zero as long as they retain their geek-oriented appeal.
Funny, I find a package manager is a much better way to install things. In Windows I have not just know where to get it, but which place is safe. In Linux, if I want firefox, I go into the package manager, and check the "firefox" checkbox. That's easy.
In Windows, I google for firefox, and get these options: www.mozilla-europe.org/ru/firefox/ , www.mozilla.ru/, www.mozilla.com/firefox/, and www.mozilla-russia.org/products/firefox/. Now the questions: are all those official, are they all up to date, and are they all controlled by the Mozilla project? I have no clue to be honest.
I can download WinSCP from: winscp.net, winscp.com, sourceforge, and softonic. Again, same problem. Sourceforge hosted projects provide extra amusement by not letting me download the file directly, but having me go through that mirror thing. And sometimes a mirror is out of date and the download doesn't work.
On the "arcane filesystem" point: You forget one small thing, and it's that the whole planet doesn't speak english yet. I see Konqueror and really everything else in Russian, but those english names would not be translated. Most people who learned english at school won't know what a "depot" or a "kernel", are, so you haven't made things any clearer for a large percentage of the population. And if you actually do translate them, how do you deal with multiple users using different languages? In the command line?
As an additional note, I love it when people pick some tiny thing as the reason why Linux isn't popular yet, when there's much bigger fish to fry. Look, most people don't even see those weird/usr and/dev directories, so it doesn't matter what they're called, because they use Ubuntu, work from a GUI, and keep their stuff in their home dir. In KDE every file browser opens in $HOME by default. On the other hand, everybody can see that the support for sound and the flash plugin still really sucks, probably within 10 minutes of trying to use the system, but for some reason nobody ever blames that for the lack of adoption.
Does anybody honestly think that the traditional Unix filesystem heirarchy makes an ounce of sense in 2009?
Yes.
In Linux you install things with a package manager. This means that for 99% of users, it doesn't matter whether it's called/usr or/Programs, they're not going to go there anyway. You're not going to install things in Linux in drag and drop style by dropping stuff into/Programs, because it's most likely not writable by normal users (never used Gobo though), and because the vast majority of applications are dynamically linked and won't work without the dependencies in place.
This just seems a pointless waste of time. As a sysadmin, this sort of thing means I have to learn where everything on this system is, and when something breaks it'll take extra effort to fix.I much prefer consistency, so this won't be the distro I'll be going with. The existence of a kernel module to keep compatibility is annoying and limiting. And this won't end there, I'm sure some other distro will think that it should be/Applications instead of/Programs. I'd rather stay with the normal layout, thanks.
As an user, everything outside of/home might as well not exist, so it doesn't matter what they call it, I don't care or notice any benefit from it. So it's a waste of time as well. Also it doesn't really make anything more intuitive, it simply moves things around./System/Settings/passwd isn't any more intuitive than/etc/passwd: It's still the same file, with the same weird formatting and editing requirements (keeping shadow in sync)
It's not really supposed to be scary, I think, it's just decoration appropiate for the setting, which can increase the creepiness.
People aren't supposed to go "Holy crap, a pentagram". It's supposed to create associations. Pentagrams are associated with satanism, which is associated with dark rituals and invocations of demons.
A stain on the floor is not scary by itself. A blood stain is worse, especially if you find it in a dark alley. A blood stain, which makes it obvious a body was dragged into a hole in the wall, on the other hand, makes you wonder who died there, why, what came out of that hole, and whether it's still lurking somewhere. That is what is supposed to be scary.
In the same way, a pentagram isn't scary by itself, but is supposed to invoke thoughts of just what the hell has been going on in this place, and what kind of horror could be lurking behind the corner.
You can have sort of that, with UPNP. Except there's no auth, so any device, including that trojaned unpatched box can ask the router to open a port for it to receive commands from the botnet.
You can't invent a "fancy crypto protocol" to prevent compromise, because if the device is compromised, the key probably is as well. Crypto is so that Alice can talk to Bob without Eve eavesdropping on them, or modifying the contents of their conversation. But it's of absolutely no use if one of the endpoints is compromised. In this case, Alice is the trojaned box, Bob is the router, and Eve probably doesn't exist, so all crypto gives you is that the trojaned box will be sure its request to open the botnet port is encrypted and hasn't been changed in transit.
Really this sort of thing has been done for one computer, with software firewalls. Say, Zone Alarm pops up a message asking "service.exe wants to listen on port 2342, allow or reject?" Well I have no clue really, without trying to figure out what that process is, and what does it want. The average user will know even less. This sort of thing will work for devices like an XBox, perhaps, where you know what an XBox is supposed to or and not. But a PC can have pretty much anything installed.
If the DSL modem were to take on that function it wouldn't even know what application is trying to get access. Did the user just install apache on port 8080? Or it's a trojan waiting for instructions?
The problem is that ultimately, if the user doesn't know and understand what is supposed to be running and what not on their computer, it can't be really automatically determined. Maybe telnet is running because it was installed automatically. Maybe it is because a trojan decided to use it to receive commands. Only the user knows whether it's supposed to be there.
Security is a hard problem that can't be solved in a fully automatic manner. You can put a lock on a door, and give people keys, but who should have the keys? What is the normal time for somebody to use their key and when is it suspicious? When should a key be taken away? It really depends on what's behind the door and what each person with access does. There's no way to have a key lock that automatically decides who should be able to get in, and when, without somebody telling it that.
It can be done well. In HL2 you can kill anything that's a danger to you, but some parts of it are still seriously creepy. Like Ravenholm, for instance.
The scary aspect doesn't come just from the danger. It's the whole setting, the headcrabs, the zombies and sounds they make, the screams when they burn... Also the scarcity of ammunition and large amount of enemies makes it difficult if not impossible to kill them all by simply shooting them.
It's all creepy to me. The fact is, it's pervasive and very difficult to opt out of as current social norms exist. Even if you don't have a gmail account, if you have even a small circle of friends there is a high chance of someone else having a gmail account that you have sent mail to, which puts your email in that circle of friends. If someone else in the same circle of friends has your picture and labels it, that would be enough to reliably link your email, first name, last name and face together. (Your friends would be identifiable as a cluster.)
I seriously understand what you mean. I started feeling uncomfortable with this years ago, so I have several separate identities and most people only know one of them. If you google for my real name, you'll only find some programming related posts in mailing lists.
Fortunately pictures of me look like this (a bit old though), and I'm not the only one who looks that way. Doing that in RL would be more complicated, maybe I'll have to invest into a fursuit;-)
On a more serious note, I think that if things continue like this, people will start keeping separate identities as a normal thing. I have 3, plus 5 or 6 disposable ones (like the youtube account). Some of the disposable ones have intentionally common names (there's got to be a lot of Aragorns out there), with the intention of making them hard to identify. Due to all the images that can be captured by Google and surveillance, I wouldn't be surprised if people started keeping a rarely seen set of clothes for going to the sex shop to be harder to identify.
Open source or commercial. WinZip's value to me is also effectively $0, since on Windows I have 7zip which does the job competently enough, and on Linux I have multiple tools to choose from.
It can get even worse, Vista's value for me for instance is negative -- I wouldn't use it even if given it for free, because I'm perfectly happy with Linux at home, and even installing it would be an inconvenience in exchange for no gain.
Even without free software such things happen: the value of a buggy whip is $0 for me, because I have no use for one.
Slashdot Mirror
It doesn't matter what license dtrace is under.
dtrace exposes Solaris kernel internals. Porting that to Linux even if the license was compatible would be very non-trivial.
BSD and Solaris at least have a common ancestry, while Linux isn't related to anything else.
Not at all. They're not simple options either. Italic or not italic is easy to understand. And most options are irrelevant in most of the cases.
In comparison, mencoder offers options such as whether to perform post-processing with a chroma or luma deblocking or deringing filter.
I have only a vague understanding of what this does, and absolutely no clue what the result will look like without trying it. This option alone will need a few minutes of research or testing to understand it, and there are a couple hundred of that kind after you're done with it.
I will repeat my main point since you can't bother with the rest of the post: The problem with mencoder isn't the interface, it's to understand what the hell it does. If you understand what is chroma and luma, and what is a deblocking filter and why would you want one, then you shouldn't have a lot of problems coming up with the right set of arguments to mencoder. If you don't know, then having those options presented through a GUI isn't going to help you much.
Sure I used a GUI app. I used many. I used Windows from 3.1 to XP, OS/2, OpenSolaris, and several Linux distros. Right now I'm typing this into Konqueror. I used various office apps, as well as Photoshop and 3D Studio for instance.
I don't rule GUIs out by any measure. In fact I do my coding in KDevelop, and have used Visual Studio quite a bit as well. Though I prefer by far prefer to use makefiles to do the build.
Btrfs is supposed to be the Linux FS that will be comparable to ZFS.
ZFS can be had through FUSE as well.
And for an alternative to dtrace there's systemtap.
I've never seen a good GUI program with such a large amount of options.
The way I imagine this coming out is something similar to the project settings in an IDE. You have settings for the compiler, linker, paths, etc, and often 3-5 subsections inside each of those.
It doesn't matter how you cut it, 385 options is a lot of stuff to represent in a GUI. If you know of a program that does something of comparable complexity in an intuitive manner, I'd love to see it.
So you can in a CLI. For example the rsync "-a" option. There's no reason why mencoder couldn't take a --preset=dvd argument or something similar.
Point. But you can't clarify everything.
Maybe it did, never used it. But please come up with a modern example. A complete GUI for mencoder would be something that would have to run on modern systems.
I said with no GUI installed. I have a Linode for instance. It's a virtualized Linux install. I guess I could run a GUI app on it anyway, but a remote GUI access across contienents would be rather painful and pointless. Much easier to let the server do the work then download the results.
By "batch processing" I mean a more automated operation btw, such as take file uploads by HTTP, put in a queue that might be internally distributed to several encoding servers, put the results somewhere.
No, I'm not. I put the cdrecord and K3B example for instance. But in general, my servers don't have any GUI on them, so any app that requires one is out of the question.
No, it's not about that. I repeat, mencoder is a low level tool. A GUI on it doesn't remove the need to understand video concepts such as PAL vs NTSC, interlacing, containers and codecs. Just like an IDE doesn't remove the need to understand programming.
An IDE may offer a window with checkboxes for optimization levels, and the help file may explain what inlining and loop unrolling do, but the manual isn't going to contain enough Computer Science information to fully understand the meanings of those options and whether they're going to benefit your program.
What I'm trying to say here is that understanding video is a much bigger problem than figuring out the UI. If you know what you need, then figuring out the required options shouldn't take very long. If you don't, then having the options represented with checkboxes isn't going to help much.
Let me quote an example from the mencoder manpage:
That'd be the hell of a GUI. According to a quick check, mencoder has about 385 possible options. A GUI that presents all those options would be incredibly complex.
At that point, IMO, a CLI interface wins by far. Why?
1. In a GUI with 20 pages of configuration with 20 options on each it's very difficult to find the current configuration state. Meanwhile on the commandline it's obvious which of the 400 options are being used.
2. Regardless of how pretty you make it, the fact is that mencoder is a low level tool, which requires understanding video concepts to use effectively. A GUI for all its features isn't going to clarify things by much.
3. Scripts are easier in a CLI environment. Telling people to check this and that option is very tedious for something with such an amount of options, and following the instructions is equally bothersome. Plain text that can be copy/pasted is a lot more convenient.
4. Why put a GUI on a tool that can be used for batch processing work? What if somebody wants to encode videos on a server, with no GUI installed?
5. Who would use a full GUI adaption of mencoder anyway? It wouldn't make it much easier for normal people. Now a GUI with a more limited purpose, such as a GUI to transcode video to the format portable players want is a lot more limited in scope, needs much fewer options, and in fact has been done already.
6. This seems like a pointless discussion anyway, since we have the best of both worlds already. For those who want scriptability, there's mencoder. For those who want a GUI there are multiple frontends for it. It's the same as burning CDs, K3B is a frontent for cdrecord, and that seems to work just fine.
That can work, assuming that:
1. The daemon runs as an user with access to sudo (exploiting the apache account won't do)
2. sudo authorization is system-wide (not true on many distros)
3. The sudo config doesn't require it to run on a tty (actual daemons don't have one)
So in theory it's doable, in practice it won't work that well on decently configured systems. For instance, in Ubuntu sudo authorization is per console. For it to work well you'd have to trick the user to start the program on the same terminal sudo will be run on.
Further difficulties can be added with for example the grsecurity patch, making the user unable to execute programs from non-root owned directories.
No, it doesn't work like that.
This came up in a previous discussion. The SMM is simply a part of the normal RAM, used for the CPUs own purposes. While the OS can't normally touch it, it's still RAM and doesn't persist across reboots.
All that putting the virus into SMM RAM means is that as memory not normally accessible by the OS, so an antivirus can't go and scan it. But something has to put the virus into the SMM RAM anyway, and that something is on the hard disk or comes from an exploit through the network.
No, not really. Realtime priority and the -rt patch do different things.
Realtime priority ensures that the pulse daemon always comes first when it comes to CPU time. This ensures that it can't happen that for instance a CPU intensive process, like a game, gcc, povray, etc doesn't let the daemon have enough CPU time to do its mixing in time. In a conflict between pulseaudio and a game wanting CPU time, pulseaudio will always win, ensuring the audio doesn't skip at the cost of the game's performance.
The -rt patch, on the other hand, reduces kernel latency. By doing that it minimizes the time the daemon has to wait, and makes it possible to use a smaller buffer. If the kernel can take say, 100ms to give control back to user space in some cases, then you must have at least a 100ms audio buffer, and that means that any audio played will always be delayed by 100ms.
I did. Did you?
I tried this a few minutes ago. top shows this as "RT" so it indeed has realtime priority. The system remains perfectly responsive, and I had no problem using "top" to check its priority, or killing it.
I first tested this years ago when I got a dual Athlon MP. Initially I booted with only one CPU, then added the second. A very noticeable difference I found was that at the time I had a buggy artsd that locked up sometimes. With one CPU, the box locked up and I could go for a coffee. After a few minutes it finally died for some reason, making it possible to use again without a reboot. Once I installed the second CPU I reproduced the bug. And absolutely no problem this time, the system remained perfectly functional.
Note that the article you linked talks about CPU affinity. Processes aren't normally locked to a single CPU, and if they are, they're usually very specific ones, like important daemons. It makes very little sense to set affinity on for instance a terminal emulator, so even if a bad RT process kills your database performance, that still shouldn't stop you from fixing the problem.
Realtime priority != realtime patch.
Realtime priority means it's got priority over anything else in the system. If it wants to run, then everything else stops.
The realtime patch is a patch to reduce kernel latency, which is good for audio or a computer that needs to react consistently and quickly to external events. But it's not related to realtime priority.
If you've got at least a dual core CPU, a stuck RT process shouldn't bring the system down. It'll use up one core, but you'll still have another to kill it.
Look in /etc/pulse/daemon.conf, there are priority and realtime settings there.
Well, and what are you going to search by, then? The way I see it, the way to do this is to encrypt the content, but provide unencrypted, searchable metadata.
What I'm saying is that the metadata often contains plenty private data. People want to hide the fact they have porn at all. Making it so that a porn collection is searchable but not viewable doesn't really help much. Mails with titles like "My wife will come home late tomorrow, let's meet" contain enough suspicious data right there that hiding the text doesn't do much good.
There's plenty meaning that can be derived from just filenames.
Does it really matter that Google or whoever can't see the exact text or images, but has enough information from filenames, tags and descriptions to accurately find out what kind of furry porn you like?
People who encrypt their data often don't want to disclose even what kind of content they have. Knowledge of what sort of porn is there, or that you're having an affair, or private internal company data are things that can be disclosed from just knowing document titles without having to even look at the exact file.
The solution to this is to take Google out of the equation. Encrypt your computer's hard disk, encrypt all your mail, build your own search database that will be stored on the encrypted disk, and search that.
But that's not a correct answer in terms of the exercise, assuming the hole is accidental and not intended.
Which is what I'm getting at. In the sentence "select 1 from dual where 1 not in (2,3,NULL)", saying there's no 1 in a list of (2,3,NULL) would be incorrect.
Why? Because the NULL stands for "missing value" in this case, which indicates that *something* must be in this place, but for whatever reason the data isn't there. So we can't say with certainty that there's no 1 in that list.
It's like I can't say that I never had a coworker called Bob, because I didn't know the names of everybody working in the company.
IIRC, OS X has quite a few versions, and many apps require a particular version precisely for this reason: in exchange for not having a package manager and dependencies like Linux, they have to either ship everything or have the OS do it.
There are advantages and inconveniences to every approach.
Self contained applications. Basically the whole /Programs idea.
Many distributions don't follow this
It's very important. Suppose that for you're a Perl coder, and for whatever reason you want to get the absolute latest development version installed, but system-wide (perhaps you're going to use it for web development). The distro won't give you the absolute latest Perl version because it's an important package: it might well stop booting if Perl gets screwed up. And if you built it yourself and installed over the the system version you might well have that problem. Then there would be the issue of how would the package manager deal with that.
So it goes in /usr/local/bin. It won't be used on boot, the package manager won't mess with it, and you can't mess anything up that way.
If you don't do this sort of thing, /usr/local is irrelevant. It should be completely empty on any system that doesn't have any packages brought in by "make; sudo make install".
You seem to be confused. /var is for permanent, but changing on-disk data. /proc is an artifical, kernel generated virtual filesystem. It doesn't exist physically on disk, and doesn't retain changes across reboots. It can't be used to store arbitrary data. Things may appear and disappear depending on connected hardware and running processes.
There seems to be a general move away from this, moving X into /usr:
Note that lib is empty, and probably kept for some backwards compatibility reason.
Modern systems will not do that, and deliver to a Maildir in $HOME.
This isn't a fixed thing, a mail server can be configured to deliver mail in different ways. You can have /var/spool/mail, maildir in $HOME, procmail, .forward, and probably a delivery into a table in a database if you want.
Because anything a NULL interacts with becomes a NULL. 1 + NULL is NULL, and so on. Which then is ultimately evaluated as false in a WHERE.
In your example, an argument could be made that you can't determine whether something exists in a list containing an undermined value.
Suppose this example:
Is there a fruit in this list of pictures?
(car) (mouse) (fox) (literal hole in the paper where a picture should be)
This question can't be answered, because you don't know what should be where the hole is.
Not that thin.
Notepad is easy to use the first time. But it's unusable if you intend to do any serious coding.
Or it just exactly as meaningless as /etc/passwd to somebody living in Russia or China, because they have no clue what "settings" or "password" mean.
Though why do they have to mess with that stuff anyway? If you're going to assume a stupid user who is going to think that /etc/passwd keeps web browser passwords and will try to delete it (how? modern friendly distros don't run as root, and won't allow that), you might as well go all the way, and pretend $HOME is /. Simply add an "user friendly mode" to the file browser in which it's locked inside $HOME, and /media is mapped to some place in $HOME, named according to the user's language settings.
Advantages: No internationalization issues, much less likely that an user will screw up system data by accident, doesn't matter how the directories are called and how they're structured.
True, but at least it's not completely different. Some things like the network settings are done differently on RH vs Debian, but the vast majority of stuff is either in the same place, or if not, in the immediate vicinity. For instance, some distros place SVN repositories in /var/svn and some in /var/lib/svn, but if you understand the organization you know it must be in /var, so that's at least a start of where to start looking.
Precisely, and we need more of it, not having each distribution come up with a new crazy scheme
Funny, I find a package manager is a much better way to install things. In Windows I have not just know where to get it, but which place is safe. In Linux, if I want firefox, I go into the package manager, and check the "firefox" checkbox. That's easy.
In Windows, I google for firefox, and get these options: www.mozilla-europe.org/ru/firefox/ , www.mozilla.ru/, www.mozilla.com/firefox/, and www.mozilla-russia.org/products/firefox/. Now the questions: are all those official, are they all up to date, and are they all controlled by the Mozilla project? I have no clue to be honest.
I can download WinSCP from: winscp.net, winscp.com, sourceforge, and softonic. Again, same problem. Sourceforge hosted projects provide extra amusement by not letting me download the file directly, but having me go through that mirror thing. And sometimes a mirror is out of date and the download doesn't work.
On the "arcane filesystem" point: You forget one small thing, and it's that the whole planet doesn't speak english yet. I see Konqueror and really everything else in Russian, but those english names would not be translated. Most people who learned english at school won't know what a "depot" or a "kernel", are, so you haven't made things any clearer for a large percentage of the population. And if you actually do translate them, how do you deal with multiple users using different languages? In the command line?
As an additional note, I love it when people pick some tiny thing as the reason why Linux isn't popular yet, when there's much bigger fish to fry. Look, most people don't even see those weird /usr and /dev directories, so it doesn't matter what they're called, because they use Ubuntu, work from a GUI, and keep their stuff in their home dir. In KDE every file browser opens in $HOME by default. On the other hand, everybody can see that the support for sound and the flash plugin still really sucks, probably within 10 minutes of trying to use the system, but for some reason nobody ever blames that for the lack of adoption.
Yes.
In Linux you install things with a package manager. This means that for 99% of users, it doesn't matter whether it's called /usr or /Programs, they're not going to go there anyway. You're not going to install things in Linux in drag and drop style by dropping stuff into /Programs, because it's most likely not writable by normal users (never used Gobo though), and because the vast majority of applications are dynamically linked and won't work without the dependencies in place.
This just seems a pointless waste of time. As a sysadmin, this sort of thing means I have to learn where everything on this system is, and when something breaks it'll take extra effort to fix.I much prefer consistency, so this won't be the distro I'll be going with. The existence of a kernel module to keep compatibility is annoying and limiting. And this won't end there, I'm sure some other distro will think that it should be /Applications instead of /Programs. I'd rather stay with the normal layout, thanks.
As an user, everything outside of /home might as well not exist, so it doesn't matter what they call it, I don't care or notice any benefit from it. So it's a waste of time as well. Also it doesn't really make anything more intuitive, it simply moves things around. /System/Settings/passwd isn't any more intuitive than /etc/passwd: It's still the same file, with the same weird formatting and editing requirements (keeping shadow in sync)
It's not really supposed to be scary, I think, it's just decoration appropiate for the setting, which can increase the creepiness.
People aren't supposed to go "Holy crap, a pentagram". It's supposed to create associations. Pentagrams are associated with satanism, which is associated with dark rituals and invocations of demons.
A stain on the floor is not scary by itself. A blood stain is worse, especially if you find it in a dark alley. A blood stain, which makes it obvious a body was dragged into a hole in the wall, on the other hand, makes you wonder who died there, why, what came out of that hole, and whether it's still lurking somewhere. That is what is supposed to be scary.
In the same way, a pentagram isn't scary by itself, but is supposed to invoke thoughts of just what the hell has been going on in this place, and what kind of horror could be lurking behind the corner.
Problem is, it's either friendly, or it's secure.
You can have sort of that, with UPNP. Except there's no auth, so any device, including that trojaned unpatched box can ask the router to open a port for it to receive commands from the botnet.
You can't invent a "fancy crypto protocol" to prevent compromise, because if the device is compromised, the key probably is as well. Crypto is so that Alice can talk to Bob without Eve eavesdropping on them, or modifying the contents of their conversation. But it's of absolutely no use if one of the endpoints is compromised. In this case, Alice is the trojaned box, Bob is the router, and Eve probably doesn't exist, so all crypto gives you is that the trojaned box will be sure its request to open the botnet port is encrypted and hasn't been changed in transit.
Really this sort of thing has been done for one computer, with software firewalls. Say, Zone Alarm pops up a message asking "service.exe wants to listen on port 2342, allow or reject?" Well I have no clue really, without trying to figure out what that process is, and what does it want. The average user will know even less. This sort of thing will work for devices like an XBox, perhaps, where you know what an XBox is supposed to or and not. But a PC can have pretty much anything installed.
If the DSL modem were to take on that function it wouldn't even know what application is trying to get access. Did the user just install apache on port 8080? Or it's a trojan waiting for instructions?
The problem is that ultimately, if the user doesn't know and understand what is supposed to be running and what not on their computer, it can't be really automatically determined. Maybe telnet is running because it was installed automatically. Maybe it is because a trojan decided to use it to receive commands. Only the user knows whether it's supposed to be there.
Security is a hard problem that can't be solved in a fully automatic manner. You can put a lock on a door, and give people keys, but who should have the keys? What is the normal time for somebody to use their key and when is it suspicious? When should a key be taken away? It really depends on what's behind the door and what each person with access does. There's no way to have a key lock that automatically decides who should be able to get in, and when, without somebody telling it that.
It can be done well. In HL2 you can kill anything that's a danger to you, but some parts of it are still seriously creepy. Like Ravenholm, for instance.
The scary aspect doesn't come just from the danger. It's the whole setting, the headcrabs, the zombies and sounds they make, the screams when they burn... Also the scarcity of ammunition and large amount of enemies makes it difficult if not impossible to kill them all by simply shooting them.
I seriously understand what you mean. I started feeling uncomfortable with this years ago, so I have several separate identities and most people only know one of them. If you google for my real name, you'll only find some programming related posts in mailing lists.
Fortunately pictures of me look like this (a bit old though), and I'm not the only one who looks that way. Doing that in RL would be more complicated, maybe I'll have to invest into a fursuit ;-)
On a more serious note, I think that if things continue like this, people will start keeping separate identities as a normal thing. I have 3, plus 5 or 6 disposable ones (like the youtube account). Some of the disposable ones have intentionally common names (there's got to be a lot of Aragorns out there), with the intention of making them hard to identify. Due to all the images that can be captured by Google and surveillance, I wouldn't be surprised if people started keeping a rarely seen set of clothes for going to the sex shop to be harder to identify.
Open source or commercial. WinZip's value to me is also effectively $0, since on Windows I have 7zip which does the job competently enough, and on Linux I have multiple tools to choose from.
It can get even worse, Vista's value for me for instance is negative -- I wouldn't use it even if given it for free, because I'm perfectly happy with Linux at home, and even installing it would be an inconvenience in exchange for no gain.
Even without free software such things happen: the value of a buggy whip is $0 for me, because I have no use for one.
Griefers seem to be getting tired or something. Lately I see much less of that sort of thing than there used to be.