The way I read it is that they want other operating systems to adopt the same infrastructure, e.g. kernel mode setting, instead of implementing an abstraction layer in Wayland itself.
> But I guess they'll be forced to add some layers sooner or later. Having too few of those can be just as bad as having too many.
The main thesis of Wayland is that they won't add abstraction layers. If you want to support the Wayland protocol on another os without Linux facilities, or if there is new hardware or changes in the drivers that don't fit the Wayland model, Wayland will not expand to those needs, but instead a new display server should be built to serve them.
Small projects to specifically fit the needs of the users, instead of one large one that expands to serve all badly.
> Small projects to specifically fit the needs of the users, instead of one large one that expands to serve all badly.
For something at the bottom doesn't the opposite principal apply(not fully/all bad but to a certain extent)? Isn't this why linux is popular for so many embedded device instead of some proprietary embeded os for instance.
If winlogon runs in the same security context and the same desktop as explorer.exe then a key logger will be able to intercept all logins, and a screenshotter will be able to take screenshots of your login screen. Clearly you don't want that to be possible.
Or are you saying that they never should have made Ctrl-Alt-Del do anything else but starting the task manager?
>> Or are you saying that they never should have made Ctrl-Alt-Del do anything else but starting the task manager?
That's what I'm saying. Not that they shouldn't have made it do anything else per se. But that by doing so, the other features caused a negative effect on the main feature.
Ctrl-Alt-Del didn't have anything to do with logon or accounts or security, just task manager. Winlogon stuff should have had a different shortcut altogether, maybe Win-Alt-Del.
Wikipedia has more details, but essentially, in the Windows NT line bringing up all the security options has always been what Ctrl-Alt-Del does, with the task manager sometimes being presented as an option. Since about 1993.
Jumping straight to the task manager was something that happened under limited circumstances (fast user switching enabled, computer unattached to a domain) in Windows XP only.
I'm not the guy who voted you down, but I'm guessing other people did it because your posts' attitude imply that new users are absolutely not worth accommodating for and that usability is not important. It comes over as rather elitist.
Your posts remind me of typical Linux-on-the-desktop-defending posts that claim Linux's usability is just fine. Making X.org work isn't difficult, just run these 4 incomprehensible commands, edit this configuration file and insert this snippet for which you have to read a 50 page manual to understand. It's easy! What, can't do it? Then you're not deserving to use Linux, but Linux is oh so user friendly! (disclaimer: I love Linux, I want it to succeed on the desktop, but this kind of attitude is helping neither Linux nor Git)
You are reading things into my post that are not there. jamesgeck0 was arguing that every single user has to configure name/email, so this is clearly a "common" case. My counter-argument was that every single user has to configure this once. The common case is to be using git in its already-configured state.
What's more, most users are going to end up setting user/email as instructed via a tutorial before they even try to make their first commit. The case of someone trying to make a commit with zero configuration while not following a tutorial is a relatively exceptional case.
And you know what? The entire premise of the argument is flawed. I just tested. If user/email is not set up, git will infer your name and email from your username and hostname. It's almost certainly going to be wrong, but it'll let you continue on your merry way without giving the obscure error that was suggested.
I haven't used RedHat-based distros for years now but I remember that back when I switched to Debian-based distros I was equally confused about Debian's package management system. I didn't think, and still don't think, that dpkg and apt are documented that well. To answer your question: yum is to rpm as apt is to dpkg. But I've always found it weird that there's a difference between apt-get and apt-cache; in contrast, "yum install" and "yum search" use the same executable. The documentation concerning building Debian packages is often out of date and scattered all over the Internet with no clear central place. And finally there's this "aptitude" thing; I still don't understand why it exists and how it's different from regular apt.
>And finally there's this "aptitude" thing; I still don't understand why it exists and how it's different from regular apt.
Aptitude is a APT frontend that solves exactly the problem you mentioned; no more `apt-cache search` nor `apt-file`, it's all just `aptitude`. Plus a little bit of dependencies tracking (which I think apt has it available for a while already). aptitude is exactly what apt should be, IMHO.
This is actually a pretty good idea. The captcha should include some kind of system for reporting slavery or other kinds of work-related abuse, whereby the reporter will be rewarded if the report results in the slavedriver being successfully prosecuted. As the number of employees become bigger, the likelihood that at least one of the employees will rat out his employer increases exponentially.
When I wrote a captcha script years ago, I included in the image the text: "Please only enter the text if you're on foobar.com", to deter people from relaying the image to a free porn site and getting horny teenagers to enter the captcha in return for porn.
Is it worth the risk to them? Their employer can grep through logs for hotkeys trivially, and it's not like typing in "help I am in a basement in Beijing" is going to send a rescue squad in 20 minutes.
I don't know. I'm just on the end-user side. Just a guess from my (pretty limited) understanding of the issue: The grsecurity[1] patch includes PaX[2] that can break a lot of software. e.g. Java and X11 and there are sometimes other unwanted side effects as well. And I've found a blog post stating that the author does not want to maintain a upstream patch[3].
There are a lot of local root exploits in Linux the past few years. But ever since Linux dropped the stable-unstable version numbering scheme, different distributions ship a wide variety of kernels + their own patches instead of "the latest kernel" because the latest may not necessarily be stable. How do I find out which local root exploits my distribution's kernel is vulnerable against, and how do I find out how quickly they get fixed? I'm on Debian 6 right now.
