Slashdot: News for Nerds


Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!



GNOME 3 To Support a "Classic" Mode, of Sorts

agrif Re:Not Thankful (197 comments)

I may be an extreme minority here, with how often people like to bash GNOME 3 at every opportunity here on slashdot. But slashdot likes to amplify vocal minorities too, so who knows.

What I do know is I honestly, really like GNOME 3. For desktops. I held off on switching for a long time because I kept hearing how it was terrible, but I finally switched about 2 weeks ago and I love it.

This is going to sound weird, considering most people describe it as bloated, but I love how minimal it is. I love how everything gets out of your way. There's no launcher, there's no desktop icons, the only permanent bar is the clock at the top. If you want to launch something, all applications are only a corner mouse throw or key press away.

I like how if I want to switch to an already open window, I just hit [Super] and type in the application name and hit enter, and it brings me to it. Most people apparently don't like how this doesn't open a new application instance, but I switch applications more often than I open new ones, and this method is a lot easier than alt-tabbing through a ton of windows or using the taskbar for me. If I really want to open a new window, I use [Control]-Enter instead. It's no big deal.

Before I switched to GNOME 3, I used XFCE with a single launcher bar attached to the middle right side of the screen, and used the option to replace the icons on the desktop with nothing, and a right-click application menu. I used the launcher bar for the 3 applications I used the most, and nothing else. So maybe my workflow was already close to what GNOME 3 expects, and maybe that's why I like it. I just want to let you know that there are people out here that do genuinely like it, because it seems like everybody here seems to think that it was a huge mistake by GNOME and everybody hates it and how could you possibly like it it's horrible. I like it.

about a year and a half ago

A Proposal To Fix the Full-Screen X11 Window Mess

agrif Re:Decimal numbers are even older. (358 comments)

You list statements I made and rebut them as if every single sentence in that post is a reason why X is bad. Sometimes the sentences are used to introduce a reason why X is bad, or provide a comparison.

X is old, which explains why it has a lot of unused code. Wayland is an example of how you can replace X with something conceptually simpler, with other benefits. Dead code increases the barrier to entry for new developers, and causes the X project itself to be organizationally huge and lumbering.

Is Vista our gold standard for how good a composited desktop can be? If we can do better than Compiz, why shouldn't we?

Writing a compositor for X is harder because X has a lot of fiddly bits that compositor authors really shouldn't have to worry about, like global window positions and probing for COMPOSITE support. The Wayland protocol delivers bitmaps to compositors, and input events from compositors to client windows. That's it.

about 2 years ago

A Proposal To Fix the Full-Screen X11 Window Mess

agrif Re:Trying to solve the wrong problem (358 comments)

I, and many others still use xterm (among other things), so you're making a false claim to support your point. That's called lying. Stop doing it.

I meant developers no longer use it. If you know of a project started in the last 5 years that decided to use these features of X, and not use GTK or Qt or some other toolkit (which themselves don't use these features), I would like to hear about it because I genuinely don't know of any.

You will still be able to run xterm under a Wayland compositor, don't worry about that.

Um yeah? And input device handling.

Input is a bit of a sticky wicket, but that's not exactly an insurmountable problem. Why should input devices be tied in with the display server (and in X's case, font rendering, vector graphics, ...)? I honestly feel like they're better off in a completely separate system that can be re-used elsewhere without bringing in all of X. Isn't that the unix philosophy?

It worked on a Sun 3/60. There is no way it could be bloated by modern standards.

See this cousin comment. All this old stuff it needs to support makes the X project huge and lumbering. Dead code stifles innovation because it scares off developers.

Those can't both be true. And the X11 API isn't really that complicated. It's quite simple if you understand it.

Yes, that is often the case with things you understand. I have tried and failed many times to understand X, I really have. I understood what the Wayland protocol does in about a day. As for the first part, code length is not the same as understandability, or even simplicity. You can have 1 kilobyte of brainfuck and 2 kilobytes of python, and the python is still simpler. Wayland provides bitmaps to compositors, and delivers input events from compositors to windows, and at no point do you need to probe some server for COMPOSITE support, or manage the child X window's global coordinates to correspond to where you're drawing them on screen, or muck around with who gets control of the root window. You get bitmaps, you draw them. You get input events, you distribute them however you please. It's really straightforward.

about 2 years ago

A Proposal To Fix the Full-Screen X11 Window Mess

agrif Re:Trying to solve the wrong problem (358 comments)

X is big and bloated, in the sense that X contains a lot of dead code. This severely limits how fast the project can move, and makes it hard to attract new developers. This is more important than (I think) most people realize. Nobody wants to work on a codebase where 90% of code isn't used (but has to keep working), and the 10% people actually do still use are all implemented as extensions. That's insane.

With regards to network transparency, see this other post of mine. I will never understand why this myth is perpetuated.

With regards to backwards compatibility, you can always run an X server on top of Wayland. It's not even particularly inefficient to do so, because Wayland is such a thin layer.

With regards to not gaining any features, removing X takes away one layer between applications and the screen. This matters, even today. If you're running a video game on a compositing window manager, that game's frame now has one less layer to pass through before it hits the screen. Using Wayland simplifies the Linux display process.

Basically, using Wayland will not prevent you from doing what you've always been doing, nor will it encourage developers to write programs that prevent you from doing what you're doing. What it will do is make it easier for those developers to make new things and be happy about it.

about 2 years ago

A Proposal To Fix the Full-Screen X11 Window Mess

agrif Re:Please stop emitting vapor from ass (358 comments)

These two files, window.c and image.c, are an entire simple GUI toolkit and an example program using that toolkit, for use with a Wayland compositor.

This directory is an entire compositing window manager that speaks the Wayland protocol. This is already impressively small, but keep in mind that most of the complexity here is in actually drawing to the screen and getting input events from hardware, something that Wayland has nothing to do with, and it's *still* small.

Wayland is simple because it is small, and it's small because it only concerns itself with communication between compositors and applications. There are already good APIs for drawing (cairo, opengl), so Wayland lets application developers use those, or whatever else crops up in the future.

about 2 years ago

A Proposal To Fix the Full-Screen X11 Window Mess

agrif Re:Dump X (358 comments)

The feature I was referring to was demo'd here, where the presenter forwards a window from one display to the other, ending up with the same window on two displays. This is local in the demo, but he says that it's transferring graphics data over the network and I have no reason to not believe him. This presentation is from last month, almost a year after the blog post you linked.

Also, X can move windows from screen to another without a problem. Most toolkits don't support it, but there has been extensions/patches around for a while.

I was not aware that this was a feature of X, but I would like to point out that this is not an *extension* of Wayland doing this, it's just a normal use of the Wayland protocol. It doesn't need special support in window managers or applications. This might also be true of X window forwarding, but you mentioned extensions/patches so it doesn't sound like it.

You know X may have some outdated APIs which are not used anymore, but it is actually a nice and extensible. Everthing Wayland can do could also be added to X as an extension (see Wayland FAQ). So giving up more than a decade of backwards compatibility for *less* features stupid.

You will still be able to run X programs with Wayland. It's just a matter of running an X server that speaks the Wayland protocol as well. That's not giving up backwards compatibility. In fact, the demo uses an X11 program (IIRC).

Just because it can be added to X doesn't mean that's the best solution. X badly needs a cleanup, there is a lot of dead weight there and using Xlib is a pain in the ass. That's a breaking change no matter how you look at it. Most of what X used to do has been pushed into other libraries that do it better (like freetype, cairo, opengl, and kernel mode setting), and it no longer makes sense for there to be a central proxy server sitting in the middle and managing it all. If you get rid of X entirely, the only thing missing is a little bit of glue for applications to talk to window managers, and the Wayland protocol provides that. It's a much simpler model that provides the same features.

about 2 years ago

A Proposal To Fix the Full-Screen X11 Window Mess

agrif Re:Dump X (358 comments)

Wayland has an X compatibility layer, sure, but you may also be pleased to know that there are efforts underway to get native Wayland network transparency.

See, the cool thing about wayland is the protocol is written to be flexible enough to have some other program handle the network transparency part, seamlessly. It's not part of the core design of wayland simply because it doesn't have to be in the core at all.

An added bonus of this flexibility is the ability to do network-tranpsarency things that even X couldn't do, like move a window from one screen to another, possibly on another computer entirely. Yes, I'm serious. It's awesome.

about 2 years ago

A Proposal To Fix the Full-Screen X11 Window Mess

agrif Re:Trying to solve the wrong problem (358 comments)

X is a very old protocol, with a lot of things that need to be implemented in order for something to say that it "speaks X". Things like font rendering and 2d drawing routines. Things that nobody actually uses anymore.

X used to be in charge of providing font rendering and such, but now libraries like Freetype and Cairo do it instead (and do it better). X used to be in charge of accelerated video, but now we have good OpenGL support and Kernel Mode Setting. The only thing X really does now is act as a proxy between window managers and applications. But X still has support for all the old stuff, and so it's huge and lumbering.

Wayland is a new protocol designed to be used between window managers and applications directly. In a new breed of window managers, the window manager itself will set up the screen and draw to it using kernel mode setting and opengl, and it will communicate and delegate windows to applications by talking the Wayland protocol. So there's nothing like the X server sitting between them anymore: the window manager runs directly on the console, and talks directly to applications.

This might sound like it would cause a lot of duplication of effort, and in one sense that's true. However, the amount boilerplate code needed to set up a simple Wayland-speaking window manager is about the same as the amount of boilerplate code needed to set up a simple X11 window manager. Except with the Wayland case, there's no huge X server sitting between applications and the screen, because Wayland is so simple the window managers can speak it directly.

One side effect of this is the Wayland library API is *much* simpler to use than the X libraries, so it becomes a lot easier to write new experimental window managers. I expect we'll see a lot of new WM's after Wayland becomes standard. Another plus is that Wayland has built-in support for multiple pointers and arbitrary window transformations, and that's an extremely nice touch for multi-touch screens.

about 2 years ago

RapidShare Urges US To Punish Linking Sites and Not File-Sharing Sites

agrif Re:War on Google (167 comments)

It might be whack-a-mole, but the law is having smaller and smaller ground to stand on.

All information is just a number; this sounds like a facetious remark but it's really central to this whole ordeal. A 3 megabyte MP3 file is an extremely large number (by our standards), usually somewhere around 2^3,000,000. A magnet URI is a much smaller number, usually around 2^128, and magnet URIs are literally just numbers.

The problem here is that current copyright law says numbers can't be copyrighted, and common sense even among non-math-literate folks says that no number should be illegal. I'm not about to argue that all data cannot be copyrighted, I'm just pointing out that there's a rather glaring inconsistency in copyright law that can be exploited by moving data needed to torrent something into a smaller string. Most people would be okay copyrighting 3 megabytes of data, but fewer would be okay with copyrighting 128 bytes. Especially if those bytes have no meaning other than just a number.

Wikipedia has a good article on Illegal Numbers. It's going to be a fun day when this all finally comes to a head.

about 2 years ago

Electronic Arts Up For Sale?

agrif Re:Dear Gaben (196 comments)

Dear Gaben, please use some of that money you keep in your money pool to buy EA, and then make it awesome.

I thought this too, for about a second. There's a lot of good IP that EA holds that could do with a very long and loving Valve-style update. But this would be a very dangerous move to make.

Valve is flat. Everybody decides for themselves what to work on. This is a hard environment to maintain, and so their hiring process is extremely important. It would be almost impossible to work in former EA employees without causing a major upset in Valve's company culture. The other option would be buying them but running them as a separate studio, which might work, but I would still fear culture leak.

about 2 years ago

Ubuntu Delays Wayland Plans, System Compositor

agrif Re:But what does it give us? (319 comments)

Everything that Wayland does is possible under X, it just might be hard to write the X code to do it.

The biggest point to Wayland is that it is extremely simple (compared to X... X is huge), and it's capable of doing 95% of what people use X for. The other 5% is network transparency, a feature I hold dearly but one that I acknowledge not many people care about.

So what's so great about simple? For one, it's easier to maintain. It's also easier to write clients for, since it's almost entirely OpenGL (the Wayland part is small). The X library is a horrible horrible thing, and I would die happy if I never have to use it again.

about 2 years ago

Ubuntu Delays Wayland Plans, System Compositor

agrif Re:Why not replace X11 with... nothing? (319 comments)

This is almost exactly what Wayland is doing. Wayland is a communication protocol between compositors and the things they composite: usually, between window managers and applications. This means that the window manager is responsible for communicating with applications, and for pushing video data on to the screen (via OpenGL + Kernel Mode Setting). So instead of launching X, then launching a window manager on top of that, you just launch the window manager.

This is the primary advantage of Wayland: it's simple. Really really simple. It's basically just OpenGL and a protocol for delegating render surfaces to other applications (to render on to using OpenGL). By comparison, an X server needs font rendering, shape rendering, and a ton of other things that aren't used today anyway because everyone uses freetype and cairo and such. Wayland leaves those out and expects you to get that from other places (like, say, freetype and cairo).

(Wayland is also the name of a C library implementing the Wayland protocol. The Wayland project also produces the Weston compositor, as a reference implementation of a simple "window manager".)

about 2 years ago

Damn Small Linux Rises From the Dead With a 4.11 RC1 Release

agrif Re:Acronyms overloading. (101 comments)

The DSL Linux CD disk is read by a LASER radiation beam.

I initially wrote this to be facetious but laser radiation beam actually sounds cool.

about 2 years ago

John Carmack: Kudos To Valve, But Linux Is Still Not a Viable Gaming Market

agrif Re:After Rage (635 comments)

Also bear in mind the relative ease of porting between OS X and Linux (kind of like porting between iOS and Android) ...

Be very careful here. Most applications written for iOS are written in Objective-C, while most applications written for Android are written in Java. Yes, they share very similar underlying design philosophies, and some of the same underlying tech (OpenGL, posix), but porting can still be very difficult. Compiling Objective-C for Android would be a nightmare, and converting Java bytecode into something compiled for iOS is similarly hard, and that's after you write an API compatibility layer.

Mobile programs are only easy to port if they were written from the beginning with porting in mind, either by using an intermediate API and langage (like MonoTouch), or by writing everything in C and keeping the Objective-C/Java parts to a minimum. Unless this was planned, most people don't go this route, and porting those programs would be more appropriately called "rewriting".

The situation between OSX and Linux is similar (though not quite as bad). Porting from Linux to OSX is easy, because most Linux programs are written in languages also available on OSX. However, OSX to Linux is hard because, again, most OSX apps are written in Objective-C. You can compile Objective-C on Linux, and a lot of OSX APIs are re-implemented by the GNUStep project, but GNUStep is missing proper support for some language features that are heavily used in OSX. Which means that native OSX apps that were not written with porting in mind become extremely hard to port.

The good news in the specific case of Steam for Linux is that almost anything available on Steam for OSX is also on Windows, which means it has already been ported, and porting to Linux shouldn't be that hard. So yes, this statement is correct in this specific case, but your comparison isn't and "it's easy to port from OSX to Linux" is an extremely common misconception.

about 2 years ago

How Will Steam on GNU/Linux Affect Software Freedom?

agrif Re:Cue the trolls... (580 comments)

As RMS mentioned, the danger is not in Linux becoming a locked down system, the danger is in people using Linux because it costs nothing rather than because it gives its users freedom. Whether you agree with RMS's stance on freedom or not, it is pretty clear that making Steam on Linux a major selling point of the platform would detract from the message of freedom.

I would also remind you that the choices we hold so dear as Linux users are a direct result of these freedoms, such as the freedom to change the software you run as you see fit. Linux itself, and the GNU tools that run on top of it, will always remain free. But Linux is also a tool for promoting the idea of freedom, and Steam on Linux might weaken that.

(Personally I can't wait for it, though.)

about 2 years ago

Feds Ban 'Buckyballs' Magnets

agrif a nice company, too (820 comments)

Me and my brother recieved the silver Buckyball cubes as Christmas gifts a few years back. These things are a blast to play with.

When one of the balls on my brothers set shattered, we called one of the listed numbers for the company to ask about maybe purchasing a replacement ball. The person on the other end was extremely interested in how this happened (apparently they hadn't had a report of a ball shattering before), and offered to send us an entire new set for free. On Christmas day. This was excellent, excellent support for an awesome product.

It's sad to hear about this.

about 2 years ago

DarwinTunes Iterates, Mixes And Culls To Create Listenable Music From Noise

agrif Re:Excellent! (53 comments)

In IP geek circles, Manfred is legendary; he's the guy who patented the business practice of moving your e-business somewhere with a slack intellectual property regime in order to evade licensing encumbrances. He's the guy who patented using genetic algorithms to patent everything they can permutate from an initial description of a problem domain – not just a better mousetrap, but the set of all possible better mousetraps.

-- Accelerando , by Charles Stross

more than 2 years ago

FreeBSD 10 To Use Clang Compiler, Deprecate GCC

agrif Re:Dropping the GPL ~= worse. (711 comments)

BSD does not guarantee access to the source; it defers this choice to whoever is distributing it.

BSD lets distributors decide whether the user has access to the source, while the GPL guarantees it. You can't do both: it's impossible to let the distributor decide whether to give the source to users and also guarantee users have access. Often, authors of BSD-licensed code choose to distribute the source for free, and it's quite possible to create a much freer environment than you can with the GPL. But the GPL guarantees access to the source and the ability to run modified sources, on every project. With BSD, you have to research each individual project to see if these rights are available, then worry about whether they will be taken away.

more than 2 years ago

FreeBSD 10 To Use Clang Compiler, Deprecate GCC

agrif Re:Dropping the GPL ~= worse. (711 comments)

I always thought about it this way: the GPL is about user freedom, and BSD is about developer freedom. If you're using GPL'd software, you are explicitly given the right to know what it's doing and the right to change it. If you're developing with BSD software, you're given the right to control how it's integrated into your project and how it's distributed. Unfortunately it's impossible to guarantee both rights at the same time; the correct choice for each project depends a lot on how that project is meant to be used.

I lean towards GPL, because there's nothing more frustrating for me as a programmer than not being able to control or fix something that's running on my computer. So when I write software, I try not to put anybody else in that position. I appreciate the appeal of BSD, though, especially when I'm working on something to sell, or on a restricted platform (like iOS).

more than 2 years ago



agrif has no journal entries.

Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account