Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror

Comment Re:I think everyone would agree here... (Score 1) 197

If most of your 900 controllers are just replicas of the standard restful controller (but... 900 different resources!?) you might be interested in the approach discussed at http://www.ruby-forum.com/topic/202398#881349 Basically you move all the restful code in one "global restful controller" and derive all the restful controllers from it, much like we derive models from ActiveRecord. Most controllers are reduced to a def/end two-liner and the application is much more maintainable because you don't have to create all the index/show/edit/update/new/create methods in every single controller. You add methods or replace the default ones only where you need to implement special logic . The code is at http://gist.github.com/280611

Comment Re:up merge justification has to be Android-agnost (Score 1) 354

This isn't obvious to LKML because most of the redesign would be in non-kernel code, but the scope of work really is that large. Google is not rejecting a better design simply out of spite; Google is rejecting the better design because the amount of effort to implement it is something that LKML would balk at doing to their own codebase.

Citation needed. Kernel people are not oblivious to userland needs. I can't say how much work it would be for Google to fix Android, but at least according to one LWN comment, Android could be made mainline-palatable without breaking userland interfaces: http://lwn.net/Articles/372631/

Some drivers would need to be modified as well, of course, but I think it's better to do the work early than late when you realise you really should've listened to the mainline developers.

Here's an interesting report from one of the realtime tree developers: http://lwn.net/Articles/372877/

Comment Re:up merge justification has to be Android-agnost (Score 1, Informative) 354

I'm not sure what you mean by "rapidly changing driver/userlevel API". The kernel userspace backwards compatibility may not be broken, so it's quite stable compared to in-kernel interfaces.

If you mean that the interfaces *need* to change, then perhaps those parts of the drivers should not be in the kernel (as is the case for 3d drivers)

I'm not at all qualified to talk about virtualisation, but regarding 3d drivers, my understanding is that a significant portion of the stack actually lives in MESA, not the kernel.

The kernel side's responsibility (assuming a "modern" one instead of the traditional "X does everything" kind of driver) is to handle details the kernel cares about such as initialisation, mode-setting, power and memory management, while providing a mostly static interface to the userspace component of the driver, which contains most of the messy 3d stuff.

I think malleable in-kernel APIs allow your driver *not* to be perfect when you merge it. Perfection is required only for any user-space interfaces.

Furthermore, if your driver suffers from bad design in some kernel subsystem, it is possible go and fix things. Or conversely, if some driver depends on an interface that you wrote, but you need to change it, that is also feasible.

Now, one might argue that it's possible to preserve the old kernel APIs, but while that is possible, it greatly increases the maintenance burden. You will need to test code that only outdated drivers use. That's a waste of resources.

Comment Re:up merge justification has to be Android-agnost (Score 0) 354

No. Drivers need to be merged to mainline. The kernel devs have been trying to hammer this point through for ages.

The reason of course is that there is no stable kernel API, and the developers are completely uninterested in maintaining one... And it's not necessary if all drivers are part of the mainline.

I know it sounds like circular logic, but the documentation at http://www.kernel.org/doc/Documentation/stable_api_nonsense.txt clarifies the reasoning.

Comment Which browser? (Score 0) 300

Which browser are you using? They're all very smooth on my macbook, using Firefox 3.6pre (daily build). CPU usage is around 10-20% (max being 200%. Dual core). Quite impressive.

I wonder if it is feasible for this to become a full-fledged flash reimplementation. As far as I understand, Actionscript is very close to Javascript anyway; if the Flash engine becomes integrated into browsers, there would be no need to load the Adobe plugin, and browser makers could ensure that Flash just works.

I guess it's better to hope that Javascript and SVG and such technologies eventually overthrow Flash, but I doubt that will happen very soon.

Comment Re:This might be a double-edged sword (Score 0) 186

I don't see how this concerns my point at all. I don't deny that it is the author's prerogative to respond however he wants, but public shaming or other abusive action right from the onset is almost always wrong.

That is, in my opinion everyone should follow the SFLC's example. If the friendly approach doesn't work, *then* you can start a campaign, and the infringing party deserves everything they get.

Comment This might be a double-edged sword (Score 0) 186

It worries me that this case has already been brought to the open.

In the previous post there were comments about contacting companies in private first and see if the problem could be solved, so that no undue negative publicity would be generated.

If this turns out to have been a false alarm, it won't reflect well on the GPL nor its proponents, and might even make more businesses wary of GPL code.

It would be interesting to see an account of the GPL violations that have been handled discreetly out of the public eye, if only to show that not everyone will be publicly shamed and vilified for breaking the licence, if they just remain cooperative.

Comment Re:Ubuntu not necessarily safe (Score 0) 281

Wine will still work even with address zero not memory-mappable. Only some applications will need it; Mostly DOS applications and others that use old APIs which might presume its availability.

I doubt setting mmap_min_addr to nonzero is going to cause problems for most people, and even if it does, in those cases the person probably will know how to configure it themselves and take the necessary precautions.

Comment How people seek out their entertainment (Score 0) 458

People have always sought out new, interesting things based on stimuli from their surroundings.
I think the ubiquity of the Internet has merely caused a decline in the importance of advertising. In the past, it was perhaps more important, but the Internet has made people more interconnected than ever before. It's easier to seek out like-minded people and find out their interests.

To put it simply, I believe the input of your "friends" is the dominant stimulus nowadays. This naturally encourages file sharing. The word of a friend alone may not be enough to cause you to spend money on something, but the threshold to download is much lower.

This kind of behaviour has the potential to expose you to a much greater amount of entertainment, as it's not limited by what the labels choose to advertise. Of course, it won't always lead to a sale, and many people will become freeloaders, but that is unavoidable.

I believe the only way to combat illegal downloading as a source of entertainment is to provide a legal solution that is both as easy to use as your favourite torrent tracker *and* price it so that the majority of people pay it for the sheer desire to be a law-abiding citizen.

As a personal anecdote, most of my books, games and DVDs I bought exactly because I had access to the material on the Internet. This includes many imports that would never be locally advertised.
The only exceptions are my PS3 games (minus a few shared PSN games). Even those I bought either after trying them myself or because I couldn't stand my friends going on about how awesome they were.

Slashdot Top Deals

You can tune a piano, but you can't tuna fish. You can tune a filesystem, but you can't tuna fish. -- from the tunefs(8) man page

Working...