Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
What's the story with these ads on Slashdot? Check out our new blog post to find out. ×

Comment Re:uh (Score 1) 427

Most of the elements of Windows 95 were not revolutionary, they were just widespread (in the consumer space), but anyway ...

The point is there's no need for these "little languages" (not so little, just not necessarily well-known to the man in the street) to do GUIs, and why would there be when perfectly good GUIs can be built in C/C++/Java/Javascript/whatever. No one in their right mind builds GUIs in Fortran, Erlang, Ada .. doesn't mean they're a time sink.

Comment Re:Finally! (Score 5, Interesting) 221

Builds in Go 1.5 will be slower by a factor of about two. The automatic translation of the compiler and linker from C to Go resulted in unidiomatic Go code that performs poorly compared to well-written Go. Analysis tools and refactoring helped to improve the code, but much remains to be done. Further profiling and optimization will continue in Go 1.6 and future releases. For more details, see these slides and associated video.

And replacing it with something slower.

Comment Re:Technically, suspend is not the problem. (Score 1) 378

Not quite. kmscon uses the same key binding format as X because it re-uses the same code.

I tried using it once, I replaced one of my consoles with kmscon and the only difference I saw was a subtle change in text colours. The fonts and other terminal behaviour seemed identical.

But it only seemed to work for me with the open source driver for nvidia cards. And that has other limitations.

Comment Re:Technically, suspend is not the problem. (Score 1) 378

To fix this would require moving the HID key value translations into the kernel keyboard driver, rather than having it (mostly) in user space in all three instances (X, Weyland, console).

Or just remove in-kernel VT consoles completely, and replace them with a user-space implementation.

Comment Re:Please explain more (Score 1) 130

newgrp is a setuid binary. During the startup of that process, if the vulnerable environment variable is set, dyld will open the requested file. Since stdin=0 / stdout=1 / stderr=2 should be the only open files, the next available file descriptor would be 3. So open() should give dyld that file descriptor.

newgrp will then drop it's privileges and run your shell, perhaps by calling exec() without forking another process. Since the file wasn't specified to close on exec, the shell will inherit the open file descriptor.

If we pass "echo "[something]" >&3" to stdin of newgrp, the echo will be executed in the new shell. Even though that shell is running as the logged in user, fd=3 was opened by root. So the result can be appended to any file you want.

The value of a program is proportional to the weight of its output.