Forgot your password?

Comment: Re:Why git? (Score 1) 213

by complete loony (#48192731) Attached to: Help ESR Stamp Out CVS and SVN In Our Lifetime
Every time I'm forced to use SVN or TFS, I'm annoyed by how difficult it is to work on multiple patches for multiple features at the same time. With git I can create my own local feature branches, and create as many versions of each patch series as I want, until I'm happy to push them for review. And I never feel like I'm at risk of losing any half finished work I've already completed.

Comment: Re:UNIX Philosophy (Score 1) 453

by complete loony (#48191167) Attached to: Debian's Systemd Adoption Inspires Threat of Fork

And then there's the launchd / inetd way of launching services that systemd also copies. The service config file can list a set of sockets that the service binds in order to service requests. For example Apache binds to port 80 and 443. So long as all services (including mounting filesystems...) describe *all* of their external interfaces, dependencies no longer matter at all.

The init system can bind all of the sockets that every service needs all at once, and either start the real service the first time the socket is used, or start them all at once. If one service connects to another, the first request will block until the other service is ready to handle it. Then all you have to worry about is the potential for deadlocking, which you'd have to consider anyway.

Comment: Re:Why? (Score 1) 222

by complete loony (#48174397) Attached to: Lead Mir Developer: 'Mir More Relevant Than Wayland In Two Years'

X the network protocol is bearable, if you are trying to use a Motif style application remotely. But almost nobody is actually doing that any more. Most GUI frameworks were just using X to push graphics buffers.

The async design of the X protocol had a number of weak points. If both the client and the server changed something, this could lead to undefined behaviour. A number of fairly simple use cases resulted in the client needing to wait for multiple network round trips. RDP is a much saner protocol in comparison.

On linux specifically the problems were even bigger. The X server was doing absolutely everything graphics related, including driving the graphics card(s) and input devices directly.

So there's been a big effort to split up the responsibilities of the X server, shifting lots of low level driver "stuff" into the kernel. Building wayland / weston to just do local window compositing. Building a vastly simplified X server that displays windows as a wayland client. And supporting other protocols like RDP for remote desktops.

Comment: Re:Has it been working so far? (Score 1) 387

by complete loony (#48164491) Attached to: Torvalds: I Made Community-Building Mistakes With Linux

People have been free to fork it and run with it. Nobody has done that.

Seriously? Forking is practically how git works, and there are lots of people running kernels with patches that aren't in mainline. Practically every distribution does this. And every embedded hardware shop.

Of course these people usually merge new changes from the mainline kernel periodically. So maybe that doesn't count for your definition of "fork".

Comment: Re:Chrome Dumbed Down (Score 1, Insightful) 68

by complete loony (#48146157) Attached to: Google Finds Vulnerability In SSL 3.0 Web Encryption

In this case, the new browser software version will break any server that only supports SSL3.0. When practically every user fails to connect to your server, including your own people, you know you have a problem to fix. Creating some work for web site owners in the interest of their own security.

I'm saying that if you gave the users the option of breaking some of the web, some small percentage of users would do it without understanding the consequences. This creates a situation that is much harder to deal with. If users report the problem to web site owners, or browser vendors, tracing the source of the problem is more difficult.

This is the same reason that Firefox no longer has a prominent option to disable Javascript. Users would disable it, then complain that web sites don't work without telling anyone that they had changed anything. The cost of supporting that option was too high.

Comment: Re:Chrome Dumbed Down (Score 0) 68

by complete loony (#48146047) Attached to: Google Finds Vulnerability In SSL 3.0 Web Encryption

Giving the user a browser option that will break compatibility with some web sites, adds more bug / support effort to work out what the user actually did. For most users, giving them an option like this is only going to cause you trouble later.

If you have too many configuration options, nobody will test every permutation to check that they actually work. Since we're talking about web browsers, most of that testing burden would fall on web site developers.

Having an option for a security setting may allow you to quickly inform users on how to mitigate a security issue. But that only works if all of your users track vulnerability news and have the capability to follow those instructions. Not true of most users of web browsers.

So IMHO, the best approach in this case is to make sure your software is secure out of the box. With no nobs that a user can toggle to break anything. Using software update channels to push security fixes when necessary.

"In order to make an apple pie from scratch, you must first create the universe." -- Carl Sagan, Cosmos