Le dimanche 01 janvier 2012 à 11:51 +0530, dE . a écrit : > I was wondering about the 2 year release cycle of Debian and it's > adaptability on the Desktops. This is bullshit. Desktop systems don’t have specific release cycle needs. Also note that the most popular desktop operating system uses a release cycle of 3 years, not 1 year. > You have to admit that Debian is not used used much on the Desktops -- > it appears to be more popular for servers; and the 2 year release cycle > is good for servers; increasing the release cycles to a higher amount is > also not bad when it comes to servers. Cause servers don't have to care > much about hardware compatibility and changes in protocols/formats > following the limited amount of task they do, or they don't require > periodic updates to installed software. This is bullshit. Server hardware can change just as much as desktop hardware. Actually, it is becoming more and more the same hardware. > On the desktops however, in the above context, things differ completely. > There's new hardware available always; within a period of 2 years, the > generation of hardware changes requiring new drivers. How is that different from servers? > An upgrade of X drivers is yet more complicated, not to mention > backporting ATI and Nvidia drivers become yet more complicated and often > impossible in a system more than 1 year old. Again more bullshit. In reality, proprietary drivers are much easier to backport, and there’s been significant progress for free drivers too. > Apart from hardware compatibility, newer standards (like HTML 5, h265, > document formats etc...) are a necessity for a the Desktops but > backporing the corresponding program may not be possible because of very > old libraries. *Very old*? Please. > Further, Desktop systems dont require that much of stability and > reliability and even security many times. This is the sentence with the highest bullshit density in your bullshit email. The largest security threat in today’s computing is certainly the terminal, as it is subject to a large amount of communication with a wide range of data of various sensibilities, making it the easiest way to expose sensible data from an open network. Desktops are the devices which require the most security attention, and in the next years this is going to shift to embedded devices as they start accessing an even wider range of data. > As a consequence, I suggest a sub-stable branch who's release cycle will > be 1 year. As compared to the stable branch, this branch should be more > flexible to upgrades and even downgrades -- our objective should be to > include the software version in the sub-stable branch which apparently > have the least bugs and other critical issues -- for e.g. KDE 4.7 has a > lot of new small bugs as compared to 4.6 -- I've to say KDE 4.6 was > better in terms of number of bugs, thus the sub-stable branch should > continue to include the 4.6 release of KDE. If a major upstream bugs or > issue is found in a package, it'll be upgraded. If you knew how our release process worked, you would understand this is bullshit too. Such proposals have been debated again and again over the years, and were never found useful. You are not looking for a distribution for desktops. You are looking for a distribution with the most recent software. There are various devices on which one could need this, including desktops, servers and embedded devices. Usually, you don’t do this on production systems, though - and that includes production desktops. No, I’m not talking about the computer you have at home with only 2 users. > Since there's a new branch, there'll be additional loads on the > developers (backports and all that), I suggest the unstable branch be > demolished (I'm not clear about it's role though) and increase the > migration time from experimental to testing. If you don’t even know what unstable is for, what the hell are you babbling about? -- .''`. Josselin Mouette : :' : `. `' `-
Attachment:
signature.asc
Description: This is a digitally signed message part