Re: shameful censoring of mono opposition
Hi, On Mon, 8 Jun 2009 07:49:32 -0400 Mark Fink wrote: > On Mon, Jun 8, 2009 at 2:37 AM, Stephan Hermann > wrote: > > Good Morning, > > > > On Sun, 7 Jun 2009 18:36:29 -0400 > > Mark Fink wrote: > > > >> [...removed totally annoying article...] > > > > As I'm not a MONO Fanboy myself...and sometimes boycott novell does > > write good articles...but please... > > > > Mono gives us a good way into the MS front...this could also be a > > point of view. > > > > And regarding Canonical...I wonder if Mark or Jane hired a lot of > > MONO people...I do think they have more python devs on their > > payrole then other companies... > > > > anyways...MONO is a technology and this technology belongs into > > Ubuntu or any other linux distribution. It helps people get rid of > > Windows in the first place. > > no it doesn't, it helps spred the infectious disease MONO. it also > helps adict users to it. Oh well...in the 80ties/90ties when Java was invented and was used by more people then Turbo Pascal in no time, I said the same...It was closed source, and had too much of Sun in it.. > > > > We can argue about "MS doesn't give us any rights on using it patent > > wise" (only to Novell) but this has really nothing to do with > > MONO...we have so many sources in our distros, which do have patent > > issues...why don't you scream about that? Oh, sorry, you want to > > watch videos, or listen to your MP3s...damn I forgot. > > read boycottnovell, Roy has proven over and over again that MONO is > illegal for anyone but microvell. "Boycottnovell" is not the truth of the world...really. I do understand the concerns, and yes, they are all very known...but again...it's your choice to accept the way Ubuntu is doing or your don't...it's your choice. Our Desktop Team choose MONO and some apps as default installation candidates and that was their choice and we live with it...if you can't live with it...then don't use it. Linux is about choice...we choose. Regards, \sh PS: Countdown to Godwins Law? -- | Stephan '\sh' Hermann| OSS Dev / SysAdmin | | JID: s...@linux-server.org | http://www.sourcecode.de/ | | GPG ID: 0xC098EFA8 | http://leonov.tv/ | | FP: 3D8B 5138 0852 DA7A B83F DCCB C189 E733 C098 EFA8 | -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: shameful censoring of mono opposition
Good Morning, On Sun, 7 Jun 2009 18:36:29 -0400 Mark Fink wrote: > [...removed totally annoying article...] As I'm not a MONO Fanboy myself...and sometimes boycott novell does write good articles...but please... Mono gives us a good way into the MS front...this could also be a point of view. And regarding Canonical...I wonder if Mark or Jane hired a lot of MONO people...I do think they have more python devs on their payrole then other companies... anyways...MONO is a technology and this technology belongs into Ubuntu or any other linux distribution. It helps people get rid of Windows in the first place. We can argue about "MS doesn't give us any rights on using it patent wise" (only to Novell) but this has really nothing to do with MONO...we have so many sources in our distros, which do have patent issues...why don't you scream about that? Oh, sorry, you want to watch videos, or listen to your MP3s...damn I forgot. So please, power up your brain first... Thx, \sh -- | Stephan '\sh' Hermann| OSS Dev / SysAdmin | | JID: s...@linux-server.org | http://www.sourcecode.de/ | | GPG ID: 0xC098EFA8 | http://leonov.tv/ | | FP: 3D8B 5138 0852 DA7A B83F DCCB C189 E733 C098 EFA8 | -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Ubuntu Desktop Unit Consistency (LP: #369525)
Hi, On Thu, 28 May 2009 23:23:42 +0200 Benjamin Drung wrote: > Hi, > > I hope this mailing list is the right place to discuss the problem. > > There is currently an inconsistency with units across the Ubuntu > desktop. Some applications (such as gvfs) use legacy units, such as a > 1024-byte kilobyte. Others (such as System Monitor) use international > standard units, such as a 1000-byte kilobyte. Ubuntu should decide its > units philosophy and apply it consistently across the desktop. It's funny to read this whole thread about pro and cons of such a change. Being myself a fan of Base2 (which means I'm old somehow), I'm not convinced about such a change only in Ubuntu. If we want to change the naming of MB (base2) into MiB (which actually is the real Base2) it needs to be done on basement level. Basement level means, that everybody needs to sit on the round table...libc, kernel, gnome, kde, linux, bsd, solaris, aix, win, cisco, uniper, etc. We are not alone...and I tend to use more then just Ubuntu on my machines...sad but true. If we don't talk about those changes in a global community, we will have a second Tower of Babel (http://en.wikipedia.org/wiki/Tower_of_Babel) My 2Cent, \sh -- Stephan '\sh' Hermann | OSS Developer & Systemadministrator JID: s...@linux-server.org | http://www.sourcecode.de/ GPG ID: 0xC098EFA8| http://leonov.tv/ 3D8B 5138 0852 DA7A B83F DCCB C189 E733 C098 EFA8 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Large files under ubuntu do not appear to work
Moins, On Wed, 25 Mar 2009 20:38:31 +0100 Jan Claeys wrote: > Op woensdag 25-03-2009 om 16:19 uur [tijdzone +], schreef Scott > James Remnant: > > On Wed, 2009-03-25 at 15:26 +, Max Bowsher wrote: > > > This assumes you buy into the SI's naming scheme and can say > > > things like "kibibyte" and "tebibyte" without bursting into > > > giggles or groaning in despair :-) > > > It isn't SI, it's IEEE > > I think it's IEEE, CIE & ISO now (although I can't be sure about ISO > as it's not freely available, but IIRC there is something mentioned > in the table of contents that is publicly available on some national > standards organisations sites). TBH, I just bursted into a laugh attackfor easyiness: 500 Gigabytes as written on a Harddrive label are not the same as 500 Gigabytes transfered over the Network (when you know HD vendor definition: kilo == 1000 and Network vendor definition normally kilo == 1024) Check for yourself...and be frustrated of different "standards" (which makes be lol again now ;)) Regards, \sh -- Stephan '\sh' Hermann | OSS Developer & Systemadministrator JID: s...@linux-server.org | http://www.sourcecode.de/ GPG ID: 0xC098EFA8| http://leonov.tv/ 3D8B 5138 0852 DA7A B83F DCCB C189 E733 C098 EFA8 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Large files under ubuntu do not appear to work
Moins, On Sun, 22 Mar 2009 13:56:00 +0200 Peteris Krisjanis wrote: > >> scsi0 : 3ware 9000 Storage Controller > >> 3w-9xxx: scsi0: Found a 3ware 9000 Storage Controller at > >> 0xd014, IRQ: 16. > >> 3w-9xxx: scsi0: Firmware FE9X 2.04.00.005, BIOS BE9X 2.03.01.047, > >> Ports: 8. > >> Vendor: 3ware Model: Logical Disk 00 Rev: 1.00 > >> Type: Direct-Access ANSI SCSI revision: 00 > > > > Well, I have identical problem with 3ware storage controller, and it > set caps something to 1.6 TB before I got the same output about very > big device. I resolved this problem with creating two raids with 1.2 > TB each. > > Obviously, it is a very interesting bug and would rock if someone > would fix it. Hopefully you play all with GPT partition labels and not with msdos labels... as for msdos labels (which is the default) you won't come over 2TB (reading as disk vendor means: 1000bytes == 1KB and not 1024bytes == 1KByte) REegards, \sh -- Stephan '\sh' Hermann | OSS Developer & Systemadministrator JID: s...@linux-server.org | http://www.sourcecode.de/ GPG ID: 0xC098EFA8| http://leonov.tv/ 3D8B 5138 0852 DA7A B83F DCCB C189 E733 C098 EFA8 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Python 3?
Hi, On Thu, 2008-12-04 at 13:01 -0700, Aaron Toponce wrote: > Chris wrote: > > Since Python 3 was released, how is Ubuntu going to transition it's PyGTK > > apps to 3.0? > > Most GNOME (and Ubuntu-centric) apps are made with Python 2.6, right? > > No. Most GNOME applications are written in C, although some may be > written in Python and other languages. > > Transitioning shouldn't be difficult. Python 2.6 was released as a > transition release to Python 3, so if any code is 2.6-compliant, it will > run in 3 without any trouble. No...not in general. Python 2.6 has a -3 compatiblity switch, and you python apps can be checked, if they would be py3k compliant. Reading Guidos article about py3k migration is really useful: http://docs.python.org/dev/3.0/whatsnew/3.0.html Regards, \sh -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Do you really want developers to be on this list was (Re: Very bad status of hardware (especially wifi) support in ubuntu, due to the too many accumulated regressions)
Hi Markus, On Thu, 2008-11-13 at 11:56 +0100, Markus Hitter wrote: > Am 13.11.2008 um 10:32 schrieb Stephan Hermann: > > > But reality told me different. > > Stephan, your points about the unfortunate truth are valid. Sad, but true. > Nevertheless, software quality is one of the keys to success. > I've just filed the second bug where one of the Gnome applets > segfaults in a standard situation. Many developers obviously code > really sloppy, a la "it worked once in my situation, so it works > always in all situations". Some developers even consider a segfault > as a normal way to end the execution of an application. This is a > more general observation of mine, this is ridiculous. > > While we can't "fix" developers, we can put more automatic helpers > into place: > > - Keep Apport enabled even on stable releases. Hiding bugs doesn't > help. > > While this doesn't fix bugs by it's self, it greatly helps to fix > them after the fact (and timely educate developers about their > practices). Yes...this can help us, to shape applications which are running actually on the user's desktops, but doesn't prevent it from happening. If the bug is found after a release, it's already too late. Well, not too late to fix it in an upcoming release, but too late today. But here is a point: Why did the bug occur after the release first, or when it occurred during development, why nobody took care to fix it? And here are some answers (hopefully not all, but some, and mostly not correct): 1. The bug occurred after the release: a) The application in question is not used by a wide range of users. If it would have been used by a broader community, the bug would have occurred during development b) Nobody, using this software before release, was actually able to file a bug report to the distro bug tracker. That's not good. And this starts another flow of questions, but those I won't raise here. 2. The bug occurred during development, why wasn't it fixed by someone? a) There was no bug report, look at 1.b) b) Most likely the application package waits in the Universe/Multiverse pocket, and no non-paid/paid dev took care, because it's not important for the release goal and nobody was interested, because it's unsupported. c) The application is in one of the supported pockets (main/restricted), the core devs had it on the radar, but decided to take it as a regression which could be fixed later, and is not so important for the release in general. d) the bug is so difficult and non-trivial to reproduce, or to fix, and the bug was pushed upstream, and the distro team just have to wait for a fix or an answer. This is belongs to the application level so far. Coming to the more delicate kernel level: > > Additionally, this opens the door to get some automatic measure about > the quality of drivers or other software. Count open bugs and you > know what you roughly can expect. If you count too many of them, drop > the hardware in the compatibility list. As said in one of my mails: The problem here is, that some users with the hardware on a list don't have problems, but others have. Now, how can we determine what the difference between the hardware is, between those with and those without problems? This task is not easy. There needs to be input from the users with the non-working hardware. Most likely, that this information can be gathered with some magic commands on CLI, which is also provided by a nice developer. But user thinks: "Damn, this takes more time, more that I want to invest in this...this OS is crap...the devs are lazy bastards, because the hardware is on the list...but as I can see, it doesn't work, wait I'll tell them that on the ML or whereever". So, for the kernel devs or other devs in other parts of the distro, it's quite difficult sometimes to get the necessary infos, when people are not coming back and providing the infos about the hardware, or if they did, then they won't come back to test the fix, because they already installed another OS or switched back to something else. There are so many variables, which are playing a part, starting from non-working hardware revision to the decision: "Ok, this card is only 10 days old, most likely that there are not many people who are using it, we need to forget about this, during this release cycle, and yes, we screw the people who have this card, but the majority is not affected at all." to "Shit, we didn't even know that this wasn't working, yeah there was a report, but we didn't get the infos back we needed to investigate..shit happens, but shit happens all the time, let's document it". And in reality, only one or two newer revisions of chipset are not working anymore...but to get this re
Re: Do you really want developers to be on this list was (Re: Very bad status of hardware (especially wifi) support in ubuntu, due to the too many accumulated regressions)
Hi, On Thu, 2008-11-13 at 09:00 +, Vincenzo Ciancia wrote: > > If a distributor adds more goodies to the kernel, then be happy, but > > that doesn't mean, that it really works...even when the distributor puts > > the hardware on the list of supported hardware. > > > > I hope this is not really the idea of the ubuntu developers on this > topic, because if so, then I can really, really forget all my bugs, and > go home happy. If the idea is that a trial-and-error process should be > the normal way of using ubuntu (it is the way I use it every time I > install it to other people), then just tell me. I think it's > unbelievable how far things went in this direction. If this is > considered normal and unharmful, there's clearly something that I didn't > understand here. This is reality :) Really. Example: I bought an USB DTV Stick for terrestrial signals. The product I bought is supported regarding all sources I read (linuxdvb, kernel...) So, I bought my hardware, regarding all infos I had access to. What was the result? In Hardy, this stick didn't work, just because the hardware vendor changed one single chip revision. And what now? Regarding the Ubuntu Kernel + all other infos, I bought a product, which just had to work out of the box. But reality told me different. Good, that upstream (those guys from linuxdvb) heard about this issue, and some guy also had this stick at home and they produced a new driver release, but this wasn't in time for Hardy. So, even if you buy hardware which should be supported by any linux distro out there, because someone put it on a list, you can't be sure, that it's actually working. Noone can and will add all different revisions of hardware chip infos on a list. What you mostly get is: ATI Graphics Card -> supported NVidia Graphics Card -> Supported USB DTV Stick Made FooBar -> Supported And then you will realize, that your very old card is not really supported anymore, even if it's an ATI or Nvidia...You will even realize that the new NVidia GeForce 10 with 8TB of RAM won't be supported, because the drivers were not finished in time... And this is nothing which only happens on Ubuntu...this happens all the time with any other distro, too. Most likely, if you use server hardware, which doesn't change so many times over three years than desktop hardware, you will be more happy. That's why most distros are not supporting a desktop version of their enterprise release. Because Desktops are really a pain for users and devs regarding hardware support. Regards, \sh -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Do you really want developers to be on this list was (Re: Very bad status of hardware (especially wifi) support in ubuntu, due to the too many accumulated regressions)
Moins, On Tue, 2008-11-11 at 02:27 +, Vincenzo Ciancia wrote: > On 11/11/2008 Scott Kitterman wrote: > > > > I would encourage you (and others, you certainly aren't the only one) > > to hold > > your temper and if you can't say something helpful, just take your > > hands off > > the keyboard. Being angry, contemptuous, and disrespectful won't get > > your > > bugs fixed faster. What it will get you is yet another list with no > > developers on it and you upset you can't get in touch with them. > > > You are perfectly right, this went out of my control, and I appreciated > a lot the responses I got on various other issues in the past. I stop > now on the topic. > > The only seriously valid point for you developers in my e-mails - I > think - and the one I wanted to expose in the first e-mail I wrote - is > that we users really need a seriously maintained hardware database, and > a serious attention to all hardware related regressions, because you > can't change your hardware like you can change your software. This is > what from times to times leads me to a complete demotivation on keeping > supporting ubuntu - and I bet you as a developer care, not of me in > particular, but of the numbers. Ubuntu is so popular because developers > care about usability and understand what it is, but also because users > are openly advertising and supporting it as if it was The Salvation from > the Evil Microsoft. Don't loose this important advantage. Advocating Ubuntu doesn't mean you need to support it. Advocating in a company and propose a switch from MS Windows XP/Vista to Canonical+Ubuntu means, that you should have a point doing so. Software in general is not bug free, so mostly you need commercial support for your OS or other Software you are using. Canonical does provide Support for Ubuntu for You, when you want to pay it. If not, fix it yourself, or help us fixing it e.g. join the irc and point people to it. If people can't help you directly, because of not having the broken hardware, you can try to provide this hardware to the people (that's an example, and hey, this you can't do when you use MS Windows). > > If you start an officially endorsed hardware database with a forum for > comments and user-to-user support in launchpad etc, and keep an eye open > on regressions in hardware support, that should promptly be acknowledged > and put aside the relevant entries in the hardware database itself, and > that ideally should never be propagated to stable releases, but > _usually_ do, I am sure your user community will make a great job in > populating it. If you don't do that because of lack of manpower... I > understand and accept the reality. You know, there is more and more hardware on the market, old and new. And I never saw any hardware working out of the box which is quite new, not even on Windows. Most drivers for new hardware on Windows are broken...and believe me, asking the hardware vendor or creator, doesn't help to fix those drivers in time, not if you don't want to pay them. BTW, I do advocate Ubuntu in every company I'm working. And mostly I'm the cursed guy who is doing the support, too. You know what? If I can't fix it in time, I'll file a bug and I'm waiting. In the meantime, there are workarounds (e.g. using an external wifi card, using another graphics card driver etc.pp.) and most people are happy when they can use their computers, it doesn't matter how. Actually most people don't care about their special hardware they have in their laptops or desktop...they just want to work. TBH, if I really want to deploy Ubuntu as Desktop replacement, I'll call Canonical or one of their partners and order some special support contracts with developer support...it costs money, yes, but this should be in your budget for such a project. But in general, you shouldn't advocate things you can't handle. If you are not able to help people out of a bad situation, don't switch them..most likely people will not only hate the new OS, but they will hate you. If you really want to know which hardware is supported, you should read the vanilla kernel mailing list, because this is the most valuable source of finding out which hardware does work out of the box. If a distributor adds more goodies to the kernel, then be happy, but that doesn't mean, that it really works...even when the distributor puts the hardware on the list of supported hardware. Regards, \sh -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Ruby on Rails support in Intrepid - call for reviewers and cheerleaders
On Wed, Aug 20, 2008 at 02:07:46PM +0100, Neil Wilson wrote: > Scott, > > I'm trying to avoid the wheres and wherefores of what gem is about. > Suffice to say that Rails depends upon effective gem support, such > that the configuration of Rails can specify gem dependencies directly. > > So if Ubuntu wants Rails, it has to have Gem that works. Therefore I > saw my task as trying to get gem to work as a user would expect it to > work without gem destroying the operating system, leaving cruft lying > around the filesystem in the wrong place and try and prevent it > running into itself too much > > It's an exercise in containment. What about teaching ROR to use an overlay, especially for the webapp you code for? I mean, the problem with gem is known...it's nasty... afaik gem can do something like a destdir install somehow (when I'm not mistaken and my mind is working in normal parameters, and my knowledge from old ROR times is still valid). If you have such a structure: /var/www/ROR_App1/<... std ror dirs ...> /var/www/ROR_App1/gems/ ... this gems dir will be used as overlay, so somehow it needs to be possible to LD_PRELOAD/LD_LIBRARY_PATH this directory (via config in apache2/lighty/whereever) > >>What are you referring to exactly ? Which use case do you have in mind ? > > > >It's my understanding that gems produces one complete package (gem) with > >all Ruby libs needed to run the application and that there is no internal > >notion of versioning. > > Think of gem as a source package that generates binary packages on the > fly. It has notions of build dependencies with other gems (including > versioning) and run dependencies. > > One thing it can do is manage several versions of the same gem on the > machine at the same time. > > For example the Rails gem depends upon the rake, activesupport, > activerecord, actionpack, actionmailer and actionresource gems. You > can install multiple different versions (usually one of each minor > revision - 1.2.6, 2.0.2 and 2.1.0) and gem will ensure that the > correct versions of the dependent gems are brought in at run time. As long as gems are only delivering their own binaries... But gems are much more, you can include complete (one or more) upstream packages (I had this at one ocasion, there was this imagemagick gem and this module was only working with a special imagemagick version, so it shipped it together with the other cruft, but instead of installing it somewhere where this imagemagick lib didn't hurt, it was just a smartass and installed it in /usr/lib, overwriting the distro imagemagick). This gem package didn't respect: DESTDIR, neither it respected the ./configure --prefix=<...> commands...so it destroyed other apps...but this wasn't documented anywhere, btw. so, having an overlay dir, where those gems can be installed without disturbing the other software, fine...but not as it is now, and not installing their stuff into /usr/local/lib or into /opt/foo Regards, \sh -- Stephan '\sh' Hermann | OSS Developer & Systemadministrator JID: [EMAIL PROTECTED] | http://www.sourcecode.de/ GPG ID: 0xC098EFA8 | http://leonov.tv/ 3D8B 5138 0852 DA7A B83F DCCB C189 E733 C098 EFA8 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Ruby on Rails support in Intrepid - call for reviewers and cheerleaders
On Tue, Aug 19, 2008 at 02:01:26PM -0700, Mathias Gug wrote: > What are you referring to by package ? > > The make a parallel with python, the gem command is similar to easy_intall. And ezinstall is broken by design for a binary distro and for endusers. ezinstall doesn't check if there is the correct version somehow installed, but downloads from questionable sources (!) .egg files. Most likely we (as packagers) are patching this away. > Neil's proposal is to improve the gem command (from the libgems-ruby > package) so that binaries are installed in /usr/local/bin (thus they're > on the default path). If you'd use install gems from the upstream > source, binaries would be installed in /usr/bin/. The goal is that gems > installed by the gem command don't interfere with ruby libraries and > binaries installed by debian packages. Don't Use Another Package System Then The One From The Distro ! Gem is just another broken package management system for ruby. Pear is just another broken package management system for php. ez_install is just another broken design fullfill dependency management system for python. I think there are others I forgot to mention. Gem packages are even more dangerous because they are delivering sometimes also binaries...which can break your current installation of the stable distro you use. Everytime I have developers in my real life work who are trying to convince me to use this system, I rather try to let them stay in front of a wall and do the chinese way of getting rid of those devs. Mostly I'll go and try to package it in a sane way, the way of my used distro. It will be more difficult but it helps the user and in this case mostly the user is the sysadmin. Developer, who are in need of the newest crack for their development can use gem or pear or ez-install without being unhappy when they destroy their system, they are developer, and they should know what they are doing. (Today this is difficult to say, because most developers don't have a clue what they are doing anyways, only when they are involved in distro specific workflows they know about the problems). I think we don't need another way of handling gem, we just need the time to package all this broken gem crack.. \sh -- Stephan '\sh' Hermann | OSS Developer & Systemadministrator JID: [EMAIL PROTECTED] | http://www.sourcecode.de/ GPG ID: 0xC098EFA8 | http://leonov.tv/ 3D8B 5138 0852 DA7A B83F DCCB C189 E733 C098 EFA8 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Disappointed with Ubuntu Server, could be used by such a wider audience
On Sun, Aug 03, 2008 at 10:40:42AM +0800, John McCabe-Dansted wrote: > On Sat, Aug 2, 2008 at 6:23 AM, Mackenzie Morgan <[EMAIL PROTECTED]> wrote: > > Because as he said, if you pre-configure everything to > > super-duper-easy-peasy, you've also pre-configured it to > > super-duper-easy-peasy-to-crack. I'm personally disappointed by > > firewalls that allow outbound by default, because something could phone > > home if I put my trust in an application I shouldn't, but they're > > easy-peasy for users, so that's what people do. I can manually go > > through and fix it myself, but if some application is running about > > opening who knows how many ports and setting god-knows-what services to > > auto-start and mucking about with insecure options in config files...how > > many months is it going to take me to track all of that down? No way. > > Commercial windows firewall pretty much all block outbound traffic by > default, popping up a dialog box offering to allow that particular > application to access the internet. I understand that it is fairly > easily for an attacker to phone home though. For example, just run > firefox http://ATTACKER/this-machine-is-cracked. Well, for firefox and doing this it needs manual intervention. For a user clicking on a malicius url, which executes some really bad javascript, this is more the type of stuff we face today. Layer 8 + 9 Problem. > However if it good practice to prevent e.g. httpd making outgoing > connections this should be done by default. It is fairly easy to do > this with e.g. systrace. http doesn't make any outgoing connection, until you connect to the httpd and it creates a >1024 connection to the client. Outgoing connection actually are not allowed by windows firewall minus all unknown system apps who are calling back to MS by default and are allowed to that on purpose. > The arguments that it is hard to step up these systems to be secure > seems to be an argument that they should be secured once, by Ubuntu, > with a great deal of scrutiny on whether the configuration really is > secure. Even if we assume that everyone will hire a UNIX guru we > can't assume that all the "gurus" really are gurus or that they won't > forget one tiny exploit. a) there is no security in general b) if there is, please read point a) > Ubuntu desktop already has one server function. I can right click a > file, go to share and share the folder using samba. If you know of any > security flaws with this GUI, please report a bug. I wonder if you share your samba drives over the internet...if so, something is a) wrong with your router, and b) I wouldn't let you do any work on my network...sounds hard, but it is. And yes, we should prevent users from doing those stupid things. Regards, \sh -- Stephan '\sh' Hermann | OSS Developer & Systemadministrator JID: [EMAIL PROTECTED] | http://www.sourcecode.de/ GPG ID: 0xC098EFA8 | http://leonov.tv/ 3D8B 5138 0852 DA7A B83F DCCB C189 E733 C098 EFA8 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Disappointed with Ubuntu Server, could be used by such a wider audience
On Sat, Aug 02, 2008 at 03:51:35PM +0800, John McCabe-Dansted wrote: > On Fri, Aug 1, 2008 at 11:25 PM, Stephan Hermann <[EMAIL PROTECTED]> wrote: > >Serious, for a normal familiy I would advise to by ready made > >appliances..they are tested, and are usable (well not everytime, but > > If a security flaw is found in such an appliance it would be much > harder to patch than one found in software. > It does have the advantage that getting root on the appliance doesn't > necessarily give you root on the PC. However we could do something > similar with VM's, chroot jails or Plash. Well, what we want is a simple tool to make families life happier, not scary. Yes, a security flaw on an appliance is serious, but having it bought from vendor X and have trust in this company I hope a security fix is on it's way. Regarding Ubuntu, yes, we do security updates, but I don't think people are following the -security ML or are interested in "XSS exploit in wordpress". Normally when you have such an appliance, everything goes automatically, and you don't need to put your hands on. Again, don't think like an expert...think like Mr. Smith and Mrs. Robinson. > > > And > > the work to stay up2date is much more then you imagine...even on Ubuntu > > and even with apt. > > You know, people with windows, they always get this little icon with > > updates available...how many of them are doing the updates everytime > > this pops up? (same question also comes for ubuntu or any linux distro > > in general). > > If a large part of the security model is having a trained monkey wait > for updates to appear and click yes then the security model and UI is > broken and should be fixed. I don't analyze updates to see if they are > "good" or not (how can I? they are binary). I can see only two > advantages to manual updates: if an update seriously breaks things we > get more warning and we can decide to not update packages that we > intend to remove. These seem easier to work around than being hacked. Ok and here it comes: Windows Updates don't say what is being fixed, actually nobody is interested, and most of the people I know are not caring about security anyways. Therefore, an automatic way of applying (security-) updates is necessary, but this integrated in the normal ubuntu desktop / ubuntu server will be a marketing desaster. For a home entertainment server this would be a good idea. > > > I do like the idea of an entainment home server or a media center > > edition of ubuntu, but it shouldn't be used for webserver or smtp > > server at home (*shiver*) > > Having e.g. a simple webserver can be a handy way of copying files > from machine to machine. Ironically it is much easier to get windows > to talk to an http server than samba. why would someone want that? If you need to copy files from one notebook to the pc, you are much more experienced then the normal family. An appliance can give you that possibility easily without thinking about it. But having all this pre-configured on ubuntu-desktop or server will again be a marketing desaster and a kick in all ubuntu pros bum. There is no easy way to give all people what they want. At least: You need to setup all yourself, or you buy a good appliance which fits your needs. Setting up all yourself without any clue about what you need to do, is IMHO a no go. Regarding the security aspect of appliances, there is a point, but I pay for it, so I have hands on the company who produced the appliance, and if they are not providing everything to make me happy and safe, there is always the possibility to go to court. Regards, \sh -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Disappointed with Ubuntu Server, could be used by such a wider audience
Hi, On Fri, 1 Aug 2008 17:04:14 +0200 Remco <[EMAIL PROTECTED]> wrote: > On Fri, Aug 1, 2008 at 3:26 PM, Stephan Hermann <[EMAIL PROTECTED]> > wrote: > > But what do you (not you in particular) want to do at home? > > > > Setting up a webserver is easy...and adding a drupal or blog > > software, too. The default apache2 package from debian/ubuntu gives > > you most of the needed setup from the time after installation. You > > just need to adjust at least your IP or your hostname, but that's > > it. No need to install dangerous third level tool which are playing > > with the config and adding mostly uneeded stuff. > > What if you want to set up a (POP+SMTP) mail server? That's a lot more > involved than just installing a package. It should be as easy as > installing it and adding allowed addresses+logins. As you said, Apache > is already that easy (though becomes more powerful with rapache), why > stop there? Fact One: an ISP who allows people running smtp servers should be punished. Private users should use an SMTP Gateway at their ISP or on some root server, but shouldn't be able to send via smtp server <-> smtp server. (HInt: Spammers are using those methods) Setting up SMTP + POP3 server is definitly nothing you want to have at home...because it's unreliable. No usecase here. People who have a clue about those topics, don't do this, only people without a clue are trying to do this. That's my opinion and good to know that many of my colleagues are agreeing here. Fact Two: I don't even see a usecase to setup a public webserver at home. Yes, freaks like me or eventually you are doing that, but we know what we do...but to be honest, I have a webserver running which is not available from the outside...for public service there are enough servers who are providing those services much better). > What about a file/music/video server? A family has bought a box which > will be used as central storage. Any computer in the LAN must have > access to it (through NFS? Samba?), and the family wants to be able to > play music by just starting Rhythmbox and discovering the server. The > same goes for videos and Totem. Well, I would say, that a DreamBox is much better as homevideobox then any linux server...ok, buy a already installed mythbuntu box or whatever...don't deal with nfs, samba ...yourself. Most partnership will break doing thisreally. Serious, for a normal familiy I would advise to by ready made appliances..they are tested, and are usable (well not everytime, but they work in the set ranges of usecases). the prices for those appliances are most of the time cheaper then to by a good PC box for doing this. Well, the usecase that people want to watch their movies on the TV you didn't mention ;) > > > but there is a difference between really doing admin work, where you > > need to touch the config files in /etc or whereever and the simple > > work you need to do at home..I know those lamp tools from windows, > > and it's horrible how those packages are degrading your system to a > > potential security risk for you and your family, because it's too > > easy to do something really stupid. > > That's what the GUI needs to prevent: doing stupid things. A GUI can > do this much better than a configuration file. A GUI usually forces a > sane configuration, while a config file has limitless possibilities. A GUI will never prevent doing stupid things. If the GUI doesn't fit your needs, there is always the risk that you start playing around with something else and make things worse...it happened in the 90ties and it will happen in the 20ties..Really, a GUI doesn't help without the knowledge of what to do. It can actually help to ease your work when you know it, but having 500 or 1000 servers it's not possible to use GUI tools, there are better tools. > For example: I can imagine a simple button for a hypothetical Ubuntu > Home Server which says: "Enable weblog". It will make sure a LAMP > server is set up properly, and some default weblog software will be > installed. Everything has been secured by default, through the system > login. It just tells the user that it can find his weblog at a certain > URL. It will also give directions for setting up the router and buying > a domain name in order to make it accessible to the world. As I said, there are companies who are providing those services much better then you will ever do at home...they do backups for you, without your interaction, they have a contract that outages are only 0.01% per year to this server etc. all those services you can't get at home. And the work to stay up2date is much more then you imagine...even on Ubuntu and even with apt. You know, people with windows, they alw
Re: Disappointed with Ubuntu Server, could be used by such a wider audience
Hi Anthony, all, On Fri, 1 Aug 2008 00:33:54 -0700 (PDT) Anthony Watters <[EMAIL PROTECTED]> wrote: > Fair comment, maybe a "Ubuntu Personal SOHO server" could be a > spinoff from Ubuntu Desktop, namely provide ClarkConnect > (http://clarkconnect.com) type install options when installing Ubuntu > Desktop? Well, I don't know this particular product, and I can't say if it will help the normal homeuser...it will help small companies (medium companies will and want to use something else), where only one or two admins are working. Administration work is timeconsuming, even when you only have a handful of servers, without using automations and admins are consuming money, too. But what do you (not you in particular) want to do at home? Setting up a webserver is easy...and adding a drupal or blog software, too. The default apache2 package from debian/ubuntu gives you most of the needed setup from the time after installation. You just need to adjust at least your IP or your hostname, but that's it. No need to install dangerous third level tool which are playing with the config and adding mostly uneeded stuff. I know usecases where those ui tools are necessary, e.g. in a small company (mostly <50 people) where the son of the boss is playing the admin because he heard of linux and he heard that internet^Wwww is easy to setup and needs to install a webserver for the homepage of this small company. Most likely those servers are hacked (or more scriptkiddied) in no time, and are used as spam gateway or whatever. I really can't recommend that. Yes, even admins are using UI tools like phpldapadmin, but those tools are not used to "setup/install/administrate the server in general", but gives a simple and plain ui for adding data to it (btwapache directory studio is much better for it ;)) but there is a difference between really doing admin work, where you need to touch the config files in /etc or whereever and the simple work you need to do at home..I know those lamp tools from windows, and it's horrible how those packages are degrading your system to a potential security risk for you and your family, because it's too easy to do something really stupid. People who are in need in having those services at home, they do already know what they need to do. People who don't know anything about those stuff, they should ask first someone who knows it. It's sad, that there are many companies and people who are announcing the easy setup of internet services (where internet == www in most cases). Back to my FMS , \sh > > - Original Message > From: Stephan Hermann <[EMAIL PROTECTED]> > To: ubuntu-devel-discuss@lists.ubuntu.com > Sent: Friday, August 1, 2008 2:32:00 PM > Subject: Re: Disappointed with Ubuntu Server, could be used by such a > wider audience > > Hi, > > I don't want to comment this mail in particular, but regarding the > difference of SysAdmins and HomeAdmins: There is a difference of > people who are used to "graphical configuration stuff which hides a > lot of important things which are important to real sysadmins". > > IMHO the usecase for Ubuntu Server is to reach the server market like > debian or rhel or sles does...not to feed the person who is coming > from the windows xp "I'm the admin" user. > > Yes, you can use even the desktop version of Ubuntu to install server > services like apache, icecast, ftpd etc. But this is not the server > usecase. > > And on a sidenote, I don't think web uis for admin work will help > to secure a root server for personal homepages. And with this web uis > I don't mean webapps like RHN or Landscape. > > Regards, > > \sh > > On Wed, 30 Jul 2008 18:14:06 -0700 (PDT) > Anthony Watters <[EMAIL PROTECTED]> wrote: > > > [...] > -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Disappointed with Ubuntu Server, could be used by such a wider audience
Hi, I don't want to comment this mail in particular, but regarding the difference of SysAdmins and HomeAdmins: There is a difference of people who are used to "graphical configuration stuff which hides a lot of important things which are important to real sysadmins". IMHO the usecase for Ubuntu Server is to reach the server market like debian or rhel or sles does...not to feed the person who is coming from the windows xp "I'm the admin" user. Yes, you can use even the desktop version of Ubuntu to install server services like apache, icecast, ftpd etc. But this is not the server usecase. And on a sidenote, I don't think web uis for admin work will help to secure a root server for personal homepages. And with this web uis I don't mean webapps like RHN or Landscape. Regards, \sh On Wed, 30 Jul 2008 18:14:06 -0700 (PDT) Anthony Watters <[EMAIL PROTECTED]> wrote: > [...] -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Need to upgrade apache2 and php5 for security reasons
Good Evening Scott, Chris and all, On Tue, 1 Jul 2008 10:06:21 -0400 Scott Kitterman <[EMAIL PROTECTED]> wrote: > On Monday 30 June 2008 10:52, Christian Desrochers wrote: > > Hi all, > > > > Our web servers have been checked recently by an external security > > firm. We have been told that our web servers need to be upgraded to > > the latest version in order to fix some security issues. Yes, that's normal, because those companies are sometimes stupid, and wasting customer's money. Actually, what you want is something like this in your production apache conf: ServerSignature Off ServerTokens Prod First, ServerSignature Off disables all apache generated footer signatures (e.g. when you have only a DirectoryListing) Second, ServerTokens Prod gives the requester nothing like: Server: Apache in your server http response header. Most companies who are doing those checks (let me guess, you need a verification for credit card handling? ;)) are now very puzzled, and telling you: "well, we can't determine your version...which is bad for us, but good for you". Another way to secure yourself is mod_security. http://www.onlamp.com/pub/a/apache/2003/11/26/mod_security.html > > > > I know that I can download and compile these programs myself, but > > for future updates, it becomes complicated since we have lots of > > servers... > > > > Currently, for Gutsy, the version of Apache is 2.2.4-3ubuntu0.1 and > > PHP is PHP5.2.3-1ubuntu6.3. > > > > Any ideas on how to softly upgrade those two packages? Yes, dapper should be updated to the latest security patch, whatever is not patched, please inform us via launchpad.net/ubuntu/+source/apache2 and file a security bug. Try to upgrade from gutsy to hardy if you can, if not, stay up2date via -security for gutsy, until gutsy is EoL. > Did this external security firm check to see what security fixes have > been added to those releases or did they just look at version > numbers? They don't do that...it's a "formal" request check...what is your apache giving us, do you have tls+smtp auth+bla enabled on your smtp server, to you support sslv3 or simple sslv2...blabla... waste of money but necessary for people who are in need of those checks. some CreditCard clearance companies want to have those reports. Regards, \sh -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Universe Freeze Imminent
On Wed, 23 Apr 2008 23:18:46 +0100 Mark Shuttleworth <[EMAIL PROTECTED]> wrote: > > Doh. That was intended for JR. Oh well, congrats to everyone else > who's been working on the KDE4 remix :-) "Oh Homer, Oh Homer..." Mark, those two mails made my day...at least those misrouting emails also happen to people who are well trained... BTW, Congrats :) \sh -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug retesting
Hi Cody, Cody A.W. Somerville wrote: > On 3/20/08, Jonathan Jesse <[EMAIL PROTECTED]> wrote: > > > > >> Good morning, >> >> How would you suggest doing this instead? I am one of those that is combing >> launchpad for bugs that have not been reported or updated for a long time. >> I try to reproduce the bugs on my own system or vm which I try to run the >> development branch. If I am unable to reproduce it myself, I always ask the >> user to try and reproduce it as well. >> So how would you suggest dealing with those bugs instead of asking the end >> user to deal with it? >> >> Jonathan >> > > They've already produced the bug if they've reported it. It is > obviously important to ask if it is reproducible every time but the > more critical information is determining _how_ to reproduce it. If you > can't reproduce it on the version they're using, then obviously you > can't assume it is fixed on the development release because you can't > reproduce it there. Although, I imagine it would be safe to close the > bug or ask for them to try and reproduce it if the version of Ubuntu > that the bug occurred on is no longer supported and you can't > reproduce the bug in a version that is supported. So, although you > test, I don't think a lot of people do. > > Goals are important here. I don't think the goal should be to close as > many bugs as possible. I believe the goal is to have as many bugs > triaged _correctly_ so that they can be dealt with effectively. > > Well sounds good...but where are the people who are doing the bugfixes? we can test, reproduce etc. Having for every bug a patch handy and an SRU is a lot of paperwork, and those uploads to -proposed won't even show up in -updates, when there is no one who is testing. So, especially for the voluntary part of Ubuntu, it's quite important for the guy/gal who is working on the package, if the bug still exists in the latest devel release...so he/she can decide to actually work on an SRU or to just go on or to fix it in latest devel release. The problem here is, as it's always, human-power :) \sh -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: libc borked
Hi, Richard Mancusi wrote: > On Mon, Mar 17, 2008 at 11:40 AM, Brian Murray <[EMAIL PROTECTED]> wrote: >> One thing this, and some other events, has made me think about is - how >> are new community members supposed to know who someone is and what their >> contributions to Ubuntu have been? We have a developer responsibilities >> wiki page[1] perhaps we should publicize it more and flesh it out. As I >> personally have a hard time keeping people's irc nicks, launchpad >> usernames and real names connected, I'm adding irc nicks to that page >> too. >> >> What other ways can we help new community members identify people >> involved in Ubuntu development? >> > > senders email signature line ... short description of responsibilities and > area > of expertise - this will help all list members place value on the reply For what? "Hello, I'm this guy, who does that and now you have to respect my mail, because I'm someone who is doing a lot more for Ubuntu then you?" Actually this occasion happened in a development cycle which is intended to break. Everbody who is using a development relase knows exactly that this can happen always until release. So there is no need for fingerpointing...We found the bugger, the solution is quite clear and for the next time, we know now what we have to do (as Colin and I were discussing). Yes, we all make mistakes, so what. To identify who is who doesn't help with all that. Regards, \sh -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: libc borked
Hi Colin, Colin Watson wrote: Fact, rebuilding the archive won't show any build failures, but running those rebuilt apps would have shown the evilness of this change. >>> Rebuilding the archive against the output of the rebuild in progress >>> would have shown it up very quickly; note that glibc 2.7-9ubuntu2 itself >>> failed to build (without hand-holding) due to upgrading to libc6 >>> 2.7-9ubuntu1 at the start of the build, and many packages would have >>> failed in the same way. >>> >> The problem I see here is: When we upload something new e.g. toolchain, >> glibc, dpkg-buildpackage changes etc. we are not automatically >> rebuilding our archive against those new versions. Which would be quite >> helpful if we did. >> > > It isn't practical for us to upload the entire archive when the > toolchain changes; we would rapidly lose mirrors if we started doing > things like that. > No, that I don't mean/want either...but an internal test rebuild of the archive should be possible without injecting any new packages to the archive/mirros. Just for QA purposes. > However, we can and do perform test rebuilds that don't end up in the > archive; in fact, such a test rebuild was performed after dpkg was > changed, but unfortunately did not make use of its own output so this > problem didn't show up. We'll fix that for the next test rebuild. We may > also try to construct a CD image from the output of the test rebuild, > which would allow us to discover more subtle problems; although we'd > have to be very careful about labelling these. > > I'm not sure if any of this would have shown up the wine problem, unless > lmms would have encountered it via its build-dependency on wine-dev. > Automatic tests in the package itself are probably the best chance we > have here. > TBH, the break of wine was just a coincidence...as I already said on IRC, I tested the wine 0.9.55 before I uploaded it, but to my fault I didn't update my personal ubuntu mirror to the latest state, and sadly on my system it worked, but not for others after upload. this has been fixed on my site with a 0,6,12,18 interval of "mirror_hardy.sh ; update_chroots.sh" via cron :) More sad is, that this bug was known to wine devs, but the corresponding bug report was set to invalid/closed which wasn't in my search query. > >> I don't blame anybody...we just need to fix some processes, e.g. >> describing a bit more what the change is (not only : ok we >> intrdoduced new cflags,ldflags handling and passing some sane/insane >> flags via dpkg-buildpackage towards our buildsystems). >> > > I still think that in general this is a sane flag (and so far it's > broken fewer packages than -fstack-protector did), but more work is > clearly needed on spotting the exceptions. > > Yepp..even with glibc working now, it can happen that some apps (like wine) are breaking during runtime (which can't be catched during the build). those buggers needs to be catched during testing the CDs, or universe archives from testers...or we find an automatic way of running the packages after building (which could be a cool project for SoC students or mad mans task ;)) Anyhow, I think we know now what went wrong, and we do better in the future :) \sh -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: libc borked
hi Colin, Colin Watson wrote: > On Thu, Mar 13, 2008 at 12:55:47PM +0100, Stephan Hermann wrote: > >> The package is not at fault... >> The fault was to upload dpkg (2008-02-11 imho) with >> https://wiki.ubuntu.com/DistCompilerFlags this in mind. >> Setting those flags is not good without a bunch of testing. >> > > I only discovered today that wine broke a few weeks ago due to this > change, and that you applied the same kind of fix to wine last week as > has since been applied to glibc. I'm curious whether you escalated this > anywhere at the time, and if so where? If it was escalated but not dealt > with, that's something we should look at too. > Well, when I upload 0.9.54 of wine, this problem wasn't arising. After this date, a new dpkg was uploaded with a change of behaviour for CFLAGS etc. This wasn't clear, just beacuse the changelog only mentioned this, without noticing WHAT actually was changed. (no clue about the difference of LDFLAGS we were passing on now) Others and I were tracking down the problem, but that the problem was with ldflags wasn't quite known until one contributor pointed us to the LDFLAGS issue. I was asking about differences between a normal manual build and our sbuilds...but actually Scott Ritchie and I (and other contributors) were quite alone with this. I can understand this, because wine is in universe and "not sooo" important. But a better communication or at least a mentioning in the changelog, what actually was changed (e.g. "New behaviour: ldflags now brings , please be careful") I for myself wasn't quite sure, if the new behaviour was tested beforehand, or just that wine was broken by some things. The funny part, this misbehaviour with our new ldflags was mentioned in a bug report from 2007 which was set invalid/closed in wines bugzilla. > >> Fact, rebuilding the archive won't show any build failures, but running >> those rebuilt apps would have shown the evilness of this change. >> > > Rebuilding the archive against the output of the rebuild in progress > would have shown it up very quickly; note that glibc 2.7-9ubuntu2 itself > failed to build (without hand-holding) due to upgrading to libc6 > 2.7-9ubuntu1 at the start of the build, and many packages would have > failed in the same way. > The problem I see here is: When we upload something new e.g. toolchain, glibc, dpkg-buildpackage changes etc. we are not automatically rebuilding our archive against those new versions. Which would be quite helpful if we did. Fun part, a change in LDFLAGS won't obviously shown up during the build process (as we saw with wine), but during runtime..(which is quite hard for devs who are running the devel release on their WS, I know, but why not use vmware ;)). > >>> I was mad. I'm human. I'm over it. Time to spend the day rebuilding 3 >>> machines. ;) >>> >> Repeat with us: You should not use Development Releases on production >> machines, until you know that it can break (badly) ! >> > > This is definitely worth noting, but it's also clearly true that > breakage should be minimised where possible. This is a reminder that the > fact that development releases are generally not actually all that bad > doesn't mean that they'll never break spectacularly, while also serving > as a demonstration of various problems in our processes. > > TBH, I'm always ready and waiting for any breakage during development..this is nothing new, and this should be known to everybody. Development releases are not intend for the normal audience, and everybody who runs a development release has to know for sure, that at some time everything breaks. I don't blame anybody...we just need to fix some processes, e.g. describing a bit more what the change is (not only : ok we intrdoduced new cflags,ldflags handling and passing some sane/insane flags via dpkg-buildpackage towards our buildsystems). Well, my fault was not to escalate this issue to the right people, just because I thought, those changes were already tested. Regards, \sh -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: libc borked
Moins, Cory K. wrote: > Soren Hansen wrote: > >> On Thu, Mar 13, 2008 at 02:00:03AM -0400, Scott Kitterman wrote: >> >> >>> Cory's comment was a bit intemperate, but I feel your response was not >>> at all helpful and that it really minimized Cory's extensive >>> contributions to Ubuntu developmen. >>> >>> >> But it's cool for Cory to flame doko because Cory's a developer? >> Interesting. >> > > If you think that was a flame then I would say you're a tad sensitive. :P > > It comes down to why would a package be uploaded at this stage in the > cycle that renders systems unbootable? > The package is not at fault... The fault was to upload dpkg (2008-02-11 imho) with https://wiki.ubuntu.com/DistCompilerFlags this in mind. Setting those flags is not good without a bunch of testing. At least, we should have rebuilt the supported archive and generate an not official released test release, just for developers, to see if something breaks (which is usally the case). Actually, there is noone to blame/flame, but this upload, with such a little change, breaks more then just glibc. Fact, rebuilding the archive won't show any build failures, but running those rebuilt apps would have shown the evilness of this change. > Carelessness? > No, just normal developer business, new stuff is good...always ;) > I could completely see if this were months ago but a day before beta > freeze? 4 weeks 'till release? I do understand sh*t happens but > something this major now shouldn't. > Of course it has to happen, because without those happenings, noone would learn from it. For the future, this is a reference that even a bag of rice, which drops on the floor of a house, could break something somewhere > I was mad. I'm human. I'm over it. Time to spend the day rebuilding 3 > machines. ;) > > Repeat with us: You should not use Development Releases on production machines, until you know that it can break (badly) ! But you are a developer and you know that, and you can deal with it :) \sh -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: How to include a part of Wine ... why include wine at all?
hi Daniel, Daniel Hollocher wrote: > Hey, good response. > It looks like this problem will be fixed in the future, and I see the > irony of to whom I originally responded to. If you see the current development release of Ubuntu (named Hardy Heron) you can see, that Ubuntu is up2date with wine. Scott Ritchie, the WineHQ Package Maintainer for Ubuntu, is working inside Ubuntu to give you, the user, the best wine experience. He is doing for WineHQ some packages of newer version of Wine for older Ubuntu Releases, but not for the Ubuntu development release. This will change in the future (hopefully) and all his effords will hit Ubuntu directly. As, I'm just the guy who is uploading Wine to ubuntu, we are using Scotts packages, there is no or little difference between Scotts and our packages for development releases. It's difficult for us, indeed, to provide more backports of newer wine versions from hardy to older releases, because of several things regarding packaging. We are in need of testers and more packagers to provide this in the future. The statement I'm making here now is this: It's not easy for People finding those repository, and if they find it, it's not easy for them, to include those 3rd party repositories into their system. Further more, we, as the MOTU team, are providing support only for packages which are in our own repositories, not for 3rd party repositories. So, if something goes wrong with a package of a 3rd Party repo, the user is alone. But he/she isn't alone with Ubuntu packages. Regards, \sh -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Proposal: cdrkit vs. cdrtools
Hi, On Mo, 2008-01-14 at 15:18 +, Matthew Garrett wrote: > On Mon, Jan 14, 2008 at 08:51:12AM -0500, Forest Bond wrote: > > > Didn't we just move back to cdrtools from cdrkit? Weren't these issues > > resolved, or something? > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=270060 > > That's from 2005. > > > Debian seems to be happy. Let's leave it be, hmm? > > No - cdrtools still links GPLed code into a CDDLed binary. It's > undistributable in its current form. So, regarding the removal of cdrtools form the archive, should we change cdrkit binary packages to Provide: the old cdrtools binary package names, and adding symlinks for the new binary tools to the old cdrtools names, like gentoo is doing so? This would be the easiest solution for now. Regards, \sh -- SysAdmin, OSS Developer GPG-Key ID: 0xC098EFA8 Fingerprint: 3D8B 5138 0852 DA7A B83F DCCB C189 E733 C098 EFA8 http://www.sourcecode.de/ -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Proposal: cdrkit vs. cdrtools
Hi, On So, 2008-01-13 at 17:29 +0100, Thilo Six wrote: > Stephan Hermann wrote the following on 13.01.2008 15:17 > > > Dear Colleagues, > > > > as I wrote on http://www.sourcecode.de/content/cdrkit-vs-cdrtools I > > really wonder what way we should go. > > > > Regarding the non-freeness of cdrtools, we should concentrate on getting > > the cdrkit binaries to the upstream projects. > > > > Most of the apps I found in debian/ubuntu, which are using mkisofs/cdrecord > > as exec calls, could be patched easily to use genisoimage/wodin. > > Having an option compatiblity between e.g. cdrecord and wodin, this should > > work out of the box. > > > > Do you think it's worth the efford? > > > > Regards, > > > > \sh > > > > PS: Discussion on u-d-d, Reply-To set please honour it. > > [quote] > For Ubuntu, cdrtools is in multiverse... > [/quote] > > according to packages.ubuntu.com cdrtools isn´t in the archive since edgy and > even in edgy it is only a transitional package only iirc. This is not correct...according to soyuz: https://edge.launchpad.net/ubuntu/+source/cdrtools/10:2.01.01a33-0ubuntu2 the last version was in gutsy...and the removal was requested on 2008-01-09. Therefore we have several packages not working anymore :) To sum up: Two ways are valid: 1. We add "Provides" to the cdrkit binary packages and install ln -s /usr/bin/ /usr/bin/ 2. We could provide patches for Debian/Ubuntu and Upstream to support both ways.. I generated a list of source packages to find out what packages are involved: Hopefully with the correct output :) Command: [EMAIL PROTECTED]:~$ for i in `grep-dctrl -F Depends,Suggests,Recommends $SEARCHTERM /var/lib/apt/lists/*binary*|grep Package|cut -d " " -f 2` ; do grep-dctrl -F Binary $i /var/lib/apt/lists/*Source* | grep Package ; done - $SEARCHTERM = mkisofs - Package: devede Package: mythplugins Package: aptoncd Package: backup-manager Package: backupninja Package: bootcd Package: nautilus-cd-burner Package: xfburn Package: burn Package: cpuburn Package: libburn Package: mp3burn Package: mybashburn Package: cdrbq Package: cdrw-taper Package: cedar-backup2 Package: debian-cd Package: dfsbuild Package: ebox Package: ebox-ca Package: ebox-firewall Package: ebox-network Package: ebox-ntp Package: ebox-objects Package: ebox-openvpn Package: jukebox-mercury Package: libebox Package: zeroc-ice Package: fai Package: fai Package: gtoaster Package: hubackup Package: ichthux-meta Package: kiso Package: live-helper Package: mindi Package: mindi-busybox Package: pybackpack Package: systemimager Package: videolink Package: xcdroast - $SEARCHTERM = cdrecord - Package: mythplugins Package: arson Package: backupninja Package: bootcd Package: nautilus-cd-burner Package: xfburn Package: burn Package: cpuburn Package: libburn Package: mp3burn Package: mybashburn Package: cdbackup Package: cdcontrol Package: cdrbq Package: cdrw-taper Package: cedar-backup2 Package: gtoaster Package: hubackup Package: ichthux-meta Package: lphoto Package: mondo Package: mp3roaster Package: dpkg-multicd Package: multicd Some of those packages do have support for cdrkit, but some of them don't. E.G. I patched qvamps to use wodim/genisoimage instead of cdrecord/mkisofs. This tool doesn't even have autodetection. So this could be a candidate for a professional cdrkit/cdrtools detection and not only a quickpatch ;) But which way we go, this should be discussed here ;) Regards, \sh -- SysAdmin, OSS Developer GPG-Key ID: 0xC098EFA8 Fingerprint: 3D8B 5138 0852 DA7A B83F DCCB C189 E733 C098 EFA8 http://www.sourcecode.de/ signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Proposal: cdrkit vs. cdrtools
Dear Colleagues, as I wrote on http://www.sourcecode.de/content/cdrkit-vs-cdrtools I really wonder what way we should go. Regarding the non-freeness of cdrtools, we should concentrate on getting the cdrkit binaries to the upstream projects. Most of the apps I found in debian/ubuntu, which are using mkisofs/cdrecord as exec calls, could be patched easily to use genisoimage/wodin. Having an option compatiblity between e.g. cdrecord and wodin, this should work out of the box. Do you think it's worth the efford? Regards, \sh PS: Discussion on u-d-d, Reply-To set please honour it. -- SysAdmin, OSS Developer GPG-Key ID: 0xC098EFA8 Fingerprint: 3D8B 5138 0852 DA7A B83F DCCB C189 E733 C098 EFA8 http://www.sourcecode.de/ signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Hardy+1 Idea: GoboLinux Filesystem Hierarchy?
Hi, Am Wed, 9 Jan 2008 13:42:43 -0600 schrieb "Conrad Knauer" <[EMAIL PROTECTED]>: > On Jan 9, 2008 5:15 AM, Guilherme Augusto > <[EMAIL PROTECTED]> wrote: > > >> http://www.gobolinux.org/?page=at_a_glance > > > > What would improve by using Gobolinux filesystem hierarchy? > > A little over a year ago SABDFL blogged on > http://www.markshuttleworth.com/archives/66 > > --- > A long, long time ago, packaging was an exciting idea. [...] Today, > these differences are just a hindrance. The fact that there are so > many divergent packaging systems in the free software world (and I > include the various *bsd's) is a waste of time and energy. [...] I'd > like to see us define distribution-neutral packaging that suits both > the source-heads and the distro-heads. > --- > > The GLFH sounds like a good way to create a standard package format > that can be easily layered over any *nix OS... Well, I don't like to interfere here with Mark, but packaging has absolutely nothing to do with a filesystem standard. Mark blogged this stuff not because we are in need of a new Filesystem Standard, but because we invent many different packaging methods for the same stuff. RPM, DEB Packages, SlackWare, this new python based packaging systen, solaris pkg, etc. A Filesystem Standard should always be applied on all unix alike and old unix operating systems. I wonder if you can apply GoboFHS to an old fart AIX unix or onto an tru64? (well, tru64 + solaris are the only real unixes on the market which a unix admin needs to work with...linux is a unix alike system and most of the admins are working on linux). Therefore introducing a complete new FSS doesn't bring any good to the world...and right now, we are not talking about the desktop here, just because until today there is not a real revenue stream to see from linux for desktop (hopefully this will change). Reading the docs of the GoboFHS this is just an add on to the normal base file system structure, therefore I think when we use our braincells in a good way, we find a better way, then symlinking stuff. A sysadmin has more clue about the system then the normal user has, which is good, so the sysadmin needs to take care about the user needs. A user just wants to save a file in a special location, let's say: My Files/Pr0n/Hot/Stuff/ This is already being the reality...so for what we need a change in /var/www/mywebsite/htdocs/foo...where user bla can't save anyways? > > On the other hand, if someone already uses Linux, he probably got > > used with the "normal" filesystem hierarchy. If it is someone's > > first time, wouldn't it be confused to have a filesystem in a way > > and every Forum, HOWTO and other help docs over the net telling how > > to do things with another filesystem hierarchy? > > "the Unix paths [...] are actually there, but they are concealed from > view using the GoboHide kernel extension. This is for aesthetic > purposes only and purely optional" IOW, the old way of doing things > should still work. Yes, but we introduce new bugs when we use a kernel extension for this. How long will GoBo support the stuff? > Also, just as an aside, I find that if I need Ubuntu help, searching > for '[my problem] Linux' isn't nearly as helpful as '[my problem] > Ubuntu'. People will adapt, just as someone moving from KDE to Gnome > will adapt to the different apps and controls. Well that's one of the problems we have right now. Many people think: linux == ubuntu and Ubuntu == linux...which is totally nonsense. When I have a problem using my Ubuntu, hopefully the same problem will occure on any other distro as well. So linux as searchterm would be the right thing to do. > I don't think the GLFH should be rejected (just) because its > different; there would never be any progress if we do that ;) The problem is not the idea, the problem is the implementation. as always. The computer was a good idea, but the implementation was a real bug ,-) (Happy Birthday Mr. Weizenbaum, Greetings to Berlin) Regards, \sh -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Hardy+1 Idea: GoboLinux Filesystem Hierarchy?
Hi Conrad, Am Wed, 9 Jan 2008 03:12:26 -0600 schrieb "Conrad Knauer" <[EMAIL PROTECTED]>: > Hardy, being a LTS release, will have an emphasis on stability and > polish; but I was thinking for Hardy+1 that, like replacing SysVInit > in Edgy with Upstart, some new ideas to kick around might be nice. > > So a suggetion: what about the GoboLinux filesystem hierarchy? > > http://en.wikipedia.org/wiki/Gobolinux > http://www.gobolinux.org/?page=at_a_glance > > It claims to be modular, logical, and "transparently retain[s] > compatibility with the Unix legacy", without any "rocket science to > this" ;) > > Sounds like fun; what say you? Crap...sorry...but when linux (or in this case Ubuntu as Linux Distro) diverts a lot from the unix standard, most people will fail to work on real Unix systems like solaris, aix, tru64 or other Unix flavours. Yeah, Linux != Unix, but it's a Unix a like, and we should follow some unix rules at least. I read about this FS hirarchy but it has IMHO some flaws and it will give us a lot more upstream divergence (upstream in this case == debian) Regards, \sh -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Appropriateness of posts to this list (Was Re: evince crash)
Hi Kevin, Am Thu, 06 Dec 2007 11:55:40 -0700 schrieb Kevin Fries <[EMAIL PROTECTED]>: > > On Thu, 2007-12-06 at 12:03 -0500, Scott Kitterman wrote: > > I think you misunderstand my point. > > No I got it. And I think that that thinking is wrong and dangerous to > Linux in general, and Ubuntu in specific. > > > > > My concern is the idea that "because a user said they want it" is a > > meaninful metric in a largely volunteer project. In Free software > > projects, the meaningful metric for what gets done is what the > > people doing the work think needs doing (and this applies to all > > types of work, not just development, in the project). Volunteers > > can't be ordered. They have to be convinced. > > If I don't get my steak the way I ordered it. I buy my steak from > elsewhere. Ubuntu with no users, is not anything but an exercise in > ego. What the customer wants is the only real metric. You need to > understand that as a developer, and I live with that every day as a > Consultant, Designer, and Implementer. The World is split into two groups: 1. OpenSource Developer who are working in companies like Novell, Canonical, RedHat, Sun etc. They are paid to work 8 or more hours on dealing with the users needs. 2. Volunteers, who are working in other businesses, have other priorities. Daily Work, Family, Friends, ..., OpenSource Development. So, there is a difference, and Scott is totally right, when he says, Volunteers needs to be convinced. Users != Customers. Customers are companies and people, who are buying Support Contracts. Those Customers are handled by the First Group. But Ricky Smith, who doesn't pay a penny, but wants something, is not a customer, but someone who could convince me or Scott to fix or prepare software for him. (Which I wouldn't do, honestly) > Which of those priorities you wish to work on, however, is completely > your own decision. But the customer MUST set the priorities of what > needs done in the bigger picture. And, the customer MUST set the list > of features that need to be implemented. So, Kevin, Pay For It. You can send us money, for doing work on what you want. Price per Hour starts at 150 Euros (without local tax). Private People like Scott or I are not in this Customer Business, that's Canonical (for Ubuntu) or other paid people in other OpenSource Companies. > Rule #1 of Business: Its not about you. It's not our business, it's our hobby, that's the difference between let's say Alan Cox (who is working for hard bucks on the Kernel) and Ricky Smith, who is sending in kernel patches, because he is interessted to fix stuff and because it's his hobby. > > If you do not make your customers wishes and desires #1 on your > priority list, your competition will. As I said, pay us then :) > > Lets not forget, Ubuntu is a business product, distributed by a real > business. Therefore, its not about you... or me. Its about the > customer. Making the customer feel like they have to talk you into > something, is just not good business. This is why I spend so many > hours providing help to ANYONE who asks. Even people I would rather > not. Its not about me, its about Ubuntu, and what is best for the > project. Ubuntu is just pool/main and pool/restricted which is mostly maintained by Canonical from paid developers. Which is good. pool/universe and pool/multiverse is community driven. Fixed, Maintained and handled by people who are not being paid by any company to do this work. > > Even more so in an all volunteer endeavor, egos must be checked at the > door. Developer's egos, designer's egos, and consultant's egos. We > as the people trying to make this a success, need to listen to the > customer so that there will be more of them. Its the one true > advantage we have over Microsoft which is notorious for blowing off > their customer to do what is in their best interest (Can we say > Windows Genuine Advantage, or Digital Rights Management... I knew we > could). Well, it's all about egos, developers are really difficult people sometimes. Without an ego you can't kick someones ass, to work on things. That's business. NO Ego, no social competence, no ass in your pants, you lose. That's why opensource is special, and not only opensource. That's why Jono wrote last time about "RockStars for OpenSource"...you need stars, you need assholes. > You allow the customers wishes to be the only real metric because you > place Ubuntu and Linux's needs before your own. Otherwise, are you > really helping? Well, you really got the point. OpenSource is Business, Business means being paid, so if you want something, please pay us people, who are dealing with software in our sparetime. Without money, no developer can live, but TBH, if this would be the usual case, most of the developers would only work for only about 8 hours on their software, and then they are leaving the office, going home to their families...and then you have, yes, the MS way. Res
