[arch-general] A universal Operating System API - why don't we have it?
Hi all It dawned on my that lots of industries have standards and companies generally keep to them. For example slabs of aluminium have standard sizes, building materials have well defined specifications, or take electrical components: there's a huge list of standardized components. You can expect between 220 and 240 VAC from your wall socket, fuses have standard formats and ratings, 1 meter here is exactly the same as 1 meter in another country, etc... Even CD's, which have been around for decades by now, have always been created using the same format (albeit extended somewhat, over time, but a normal CD pressed now should still play in a CD player that's 20 years old). It allows for a very competitive market where choices are made based on price, quality, availability, etc... Why doesn't the computer business have something similar? Sure processors are interchangeable in a limited way, we use standardized RAM, standard interfaces for accessing our peripherals, etc... But not when it comes to software. Why don't we have one universal API that works on every operating system? Yes there is libc, the language C is defined in some way, but I'm talking about stuff that would make applications 100% portable. Things like enumerating all hardware devices, configuring a network interface, drawing a window, ejecting the CD-ROM drive, getting notified about new hardware plugged in, etc... It's different on every operating system. You cannot write a driver for Linux and expect it to work on FreeBSD. You cannot write an application for windows and expect it to work on Linux. When you buy a piece of hardware you usually hope for the best that it'll work out-of-the-box including all extra features. So why is that? Why hasn't someone stepped up and even try and create a universal operating system API? Is it because the computer business is still a child in some way, compared to other industries? Just a thought. Glenn
Re: [arch-general] A universal Operating System API - why don't we have it?
2009/12/18 RedShift redsh...@pandora.be: Hi all It dawned on my that lots of industries have standards and companies generally keep to them. For example slabs of aluminium have standard sizes, building materials have well defined specifications, or take electrical components: there's a huge list of standardized components. You can expect between 220 and 240 VAC from your wall socket, fuses have standard formats and ratings, 1 meter here is exactly the same as 1 meter in another country, etc... Even CD's, which have been around for decades by now, have always been created using the same format (albeit extended somewhat, over time, but a normal CD pressed now should still play in a CD player that's 20 years old). It allows for a very competitive market where choices are made based on price, quality, availability, etc... Why doesn't the computer business have something similar? Sure processors are interchangeable in a limited way, we use standardized RAM, standard interfaces for accessing our peripherals, etc... But not when it comes to software. Why don't we have one universal API that works on every operating system? Yes there is libc, the language C is defined in some way, but I'm talking about stuff that would make applications 100% portable. Things like enumerating all hardware devices, configuring a network interface, drawing a window, ejecting the CD-ROM drive, getting notified about new hardware plugged in, etc... It's different on every operating system. You cannot write a driver for Linux and expect it to work on FreeBSD. You cannot write an application for windows and expect it to work on Linux. When you buy a piece of hardware you usually hope for the best that it'll work out-of-the-box including all extra features. So why is that? Why hasn't someone stepped up and even try and create a universal operating system API? Is it because the computer business is still a child in some way, compared to other industries? Just a thought. Glenn Isn't this what POSIX was, albeit quite old now, but still a standard?
Re: [arch-general] A universal Operating System API - why don't we have it?
For example slabs of aluminium have standard sizes I would guess there are at least 50 different standards available for alu plates. But the difference to the computer world is, you can take any of that plates, drill a hole and mount stuff. building materials have well defined specifications With an emphasis on specification_s_. Sometimes it's troublesome to keep up with the changes (or complete overhauls). So why is that? Why hasn't someone stepped up and even try and create a universal operating system API? Is it because the computer business is still a child in some way, compared to other industries? Computers are still in it's childhood, i would say, too. I would say, if you create such unified API now, you would delimit the functionalty to the intersection of all hardware that is now availbale. If everybody would develop on this base, it would lead to restricted (and slow) software. (I'm no programmer, so i mighty be wrong here.) But i think we already have a big abstraction level in software nowadays. Think of Java or Python. Nobody has to write everything in assembler. I think things have to iron out themselves in the computer bussines. I read today about the computer simulation of the construction of the roof from the munich Olypmic stadium. The result of that calculations is on 600.000 punched cards. That was only 25 years ago. Now think of what long way metallurgy has gone in our history. So i think it is too early for hat. Most people even don't know, what they want from computers. Cheers, Fabian
Re: [arch-general] Good press at distrowatch.com
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 18 Dec 2009 01:40:24 -0600 Jonathan Temple jontem...@gmail.com wrote: On Thu, Dec 17, 2009 at 11:50 PM, David C. Rankin drankina...@suddenlinkmail.com wrote: Seriously, I like the Arch installer just fine, but I can tell you that the Ubuntu/SuSE install rating most likely come from the fact that the gui installers they employ are easy on the eye and they have put a lot of effort into automating the difficult parts of the install procedure that most new users don't understand -- the partitioning. This begs the question: does arch really want users who can't get through the current installer? Isn't the user base Arch Linux is catering to one that /should/ understand this? +1 - -- Myles Green Linux. It isn't about it being free, it's about the freedom it brings. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAksrYckACgkQ1TmPUtHwHkey+wCdF1KXP5jVTkjVobtNf0qn4Dq8 3KEAmgMZYJDPmRD86BNoDkGlXVeZPonU =Gpdm -END PGP SIGNATURE-
Re: [arch-general] Good press at distrowatch.com
Myles Green wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 18 Dec 2009 01:40:24 -0600 Jonathan Temple jontem...@gmail.com wrote: On Thu, Dec 17, 2009 at 11:50 PM, David C. Rankin drankina...@suddenlinkmail.com wrote: Seriously, I like the Arch installer just fine, but I can tell you that the Ubuntu/SuSE install rating most likely come from the fact that the gui installers they employ are easy on the eye and they have put a lot of effort into automating the difficult parts of the install procedure that most new users don't understand -- the partitioning. This begs the question: does arch really want users who can't get through the current installer? Isn't the user base Arch Linux is catering to one that /should/ understand this? +1 - -- Myles Green Linux. It isn't about it being free, it's about the freedom it brings. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAksrYckACgkQ1TmPUtHwHkey+wCdF1KXP5jVTkjVobtNf0qn4Dq8 3KEAmgMZYJDPmRD86BNoDkGlXVeZPonU =Gpdm -END PGP SIGNATURE- Good thing you signed that message... it would be a shame if we did not know that +1 was definitely from you. Allan
Re: [arch-general] A universal Operating System API - why don't we have it?
I think it's because computers develop too quickly to have it. Some of the other things you mention such as building materials have been around for years, even centuries, and are the way they are going to be. I think if someone developed a bright new way of creating aluminum ingots for instance, that the aluminum industry would be thrown into chaos because some of the old way of doing it wouldn't fit, just in the way the computer industry is now. When the computer industry settles down and quits developing so quickly then it will have a certain accepted way of doing things too. Of course then it won't be nearly as interesting, and I for one, if I'm still around by that point, will have to find something else to tinker with.
Re: [arch-general] Thunderbird bugging with Lightning + Enigmail
Le 18/12/2009 08:33, Magnus Therning a écrit : Go to http://enigmail.mozdev.org/download/index.php you'll be able to put in the combination linux (x86_64) and Thunderbird 3.0 (thanks to a fellow Arch user it seems :-) Hi there, I'm the maintainer of the enigmail package on AUR, and I've contributed x86_64 builds of Enigmail since the 0.95.7 release. The .xpi on the website is built using the AUR package, so both are good ;) That's the add-on I'm using at home. Do note that the reports of incompatibility between lightning and enigmail are fully true, i.e. have both add-ons enabled and you'll loose some text in your menu, disable either and everything looks good again. Irritating indeed! I have both Lightning and Enigmail too, but I have never encountered any problem. May this be related to a GTK theme or something like this? Cheers, -- Thomas/Schnouki signature.asc Description: OpenPGP digital signature
Re: [arch-general] A universal Operating System API - why don't we have it?
There are things like that (think NDIS - it's Microsoft, but it's a step in the right direction), just not enough , but I think it's a question of time. -- catwell
Re: [arch-general] A universal Operating System API - why don't we have it?
On 12/18/2009 01:26 AM, Damien Churchill wrote: Isn't this what POSIX was, albeit quite old now, but still a standard? imagine that: some people out there still think posix is THE standard and people should read the spec BEFORE reimplementing basics in the name of making things cross platform. even windows gains more posix implementation every version. The only ones actually going slowly AWAY from the standard are the GNUs. -- Arvid Asgaard Technologies
Re: [arch-general] Good press at distrowatch.com
On Fri, Dec 18, 2009 at 06:17, Allan McRae al...@archlinux.org wrote: Good thing you signed that message... it would be a shame if we did not know that +1 was definitely from you. Allan +1
Re: [arch-general] Good press at distrowatch.com
I liked the Arch installer except I would liked to have a different partitioner as I find the current one's interface to be quite cumbersome in comparison to say the partitioner that is in the Debian installer. Otherwise the Archlinux installer is very simple in my opinion. Best regards Nicklas W Bjurman On Fri, Dec 18, 2009 at 3:59 PM, Daenyth Blank daenyth+a...@gmail.com wrote: On Fri, Dec 18, 2009 at 06:17, Allan McRae al...@archlinux.org wrote: Good thing you signed that message... it would be a shame if we did not know that +1 was definitely from you. Allan +1
[arch-general] Firefox Themes Will Not Install / Disabled - Unsecure Extenstion Updates
Guys, After the latest firefox updates, most of my themes were disabled and new themes would not install. After the automatic update check tried to install the Foxide Graphite theme, I found out why. During the install, I received a messages telling me that firefox would not install the theme because it did not provide a secure update path. Digging a little bit disclosed the following: http://kb.mozillazine.org/Unable_to_install_themes_or_extensions_-_Firefox Unsecured updating Firefox 3 and above: Starting in Firefox 3, if an add-on does not provide a secure method of auto-updating then, by default, Firefox will refuse to install the add-on. If you have add-ons already installed that are insecure in this way, they will be automatically disabled. [6] Add-ons from AMO (https://addons.mozilla.org/) and other secured sites are not a problem; for add-ons that do provide a secure updating method, advanced users can add the preference extensions.checkUpdateSecurity (http://kb.mozillazine.org/Extensions.checkUpdateSecurity) and set it to false (not recommended). See this article: http://developer.mozilla.org/en/docs/Extension_Versioning%2C_Update_and_Compatibility#Securing_Updates and bug 378216 (https://bugzilla.mozilla.org/show_bug.cgi?id=378216) for more information. For testing purposes only, I added extensions.checkUpdateSecurity (booleen = false) to about:config and magically, all of my themes were working again. (Note: this is not advisable due to security concerns, use with discretion) (ps - I know this is a cross post ;-) -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
Re: [arch-general] A universal Operating System API - why don't we have it?
On Fri, Dec 18, 2009 at 3:26 AM, Damien Churchill dam...@gmail.com wrote: Isn't this what POSIX was, albeit quite old now, but still a standard? POSIX and the SUSv3 (Single Unix Specification)
Re: [arch-general] A universal Operating System API - why don't we have it?
Pierre Chapuis catw...@archlinux.us writes: There are things like that (think NDIS - it's Microsoft, but it's a step in the right direction), just not enough , but I think it's a question of time. And then there's the UDI (universal driver interface) (UDI), which Stallman doesn't like. I can certainly see arguments for both sides of that issue. As an aside, I interviewed for a job with MS last year. At some point, the device driver issue was discussed. One of my interviewers made the comment that a universal driver interface would be a bad thing, because it reduces competition. I don't think that they like commoditized things at all. -- Chris
Re: [arch-general] Good press at distrowatch.com
1) This begs the question: does arch really want users who can't get through the current installer? Isn't the user base Arch Linux is catering to one that /should/ understand this? definitely. in fact, i think our current interactive installer is already too complicated/userfriendly. there have been some discussions about this already. E.g. http://mailman.archlinux.org/pipermail/arch-releng/2009-August/000721.html 2) for those who say partitioning is too difficult - have you tried the automatic partitioning in aif (very similar to the one in old /arch/setup btw)? can't go much easier then that imho. except maybe if the user doesn't even know what an ext3 is. 3) On Thu, 17 Dec 2009 23:50:12 -0600 David C. Rankin drankina...@suddenlinkmail.com wrote: No, No, No.. Dieter, you are looking at it all wrong. You are approaching it like an engineer or scientist sees things. (...) very funny :) If I had two suggestions for the arch installer, it would be theses: (..) that would make things even more complicated. You're right though that those points are the biggest diffs with other installers. especially the package selection. but i don't think we should implement it in the core of aif. See also http://bounty.archlinux.ca/projects/3/ The config files are so powerful you can just add whichever repositories you need and add packages/groups to install whatever you want. http://github.com/Dieterbe/aif/blob/master/examples/generic-install-on-sda This should also answer Denis' question. I agree with Dieter, that the install should be measured by speed and automation -- but long ago I realized that there a whole lot of other people out there that just don't think like me :p Don't misunderstand me. An interactive hold-your-hand-a-bit installation processes is a good thing for many use cases (if implemented correctly). There are many ways to judge installations by. I'm only saying: if one chooses to judge an installation system by the criterion of speed, then (s)he better gets his/her facts right before calling our approach slow[er]. Dieter
Re: [arch-general] A universal Operating System API - why don't we have it?
On Fri, Dec 18, 2009 at 5:31 PM, Chris Brannon cmbranno...@gmail.com wrote: Pierre Chapuis catw...@archlinux.us writes: There are things like that (think NDIS - it's Microsoft, but it's a step in the right direction), just not enough , but I think it's a question of time. And then there's the UDI (universal driver interface) (UDI), which Stallman doesn't like. I can certainly see arguments for both sides of that issue. As an aside, I interviewed for a job with MS last year. At some point, the device driver issue was discussed. One of my interviewers made the comment that a universal driver interface would be a bad thing, because it reduces competition. I don't think that they like commoditized things at all. Was that a private joke or something ? :) The only thing MS has ever done or tried to do is killing competition. And who writes drivers ? Isn't it / shouldn't it be the hardware makers who designed the hardware in the first place ? And most of them probably invest 99% of the resources for Windows, and 1% for all the other os. Well it probably depends a lot on the hardware/drivers we talk about, so it is probably difficult to stay general. And to be honest, I probably don't have a good picture of it. But it just sounds like a funny argument to me.
Re: [arch-general] Good press at distrowatch.com
On Fri, Dec 18, 2009 at 11:54 AM, Dieter Plaetinck die...@plaetinck.be wrote: The config files are so powerful you can just add whichever repositories you need and add packages/groups to install whatever you want. http://github.com/Dieterbe/aif/blob/master/examples/generic-install-on-sda This should also answer Denis' question. It's probably only a matter of time before somebody releases a config file for installing a set of packages similar to a typical desktop distro, such as Ubuntu. Then Arch installer might become one of the fastest among all distributions, both in terms of actual speed and perceived speed from the user's perspective. You boot, you type aif -p automatic -c /usr/share/aif/examples/gnome-install-on-sda, you wait a bit and then you have a complete and up-to-date desktop system. No clicking 'next, next, next...' ad nauseam, no silly little choices to make. There's a pitfall though: too many possible config files and you're forcing a user to make a choice he or she doesn't care about :) Users familiar with Linux will most likely want to create personalized config files for their own needs and wouldn't rely on pre-made templates. A bit idealistic view, perhaps, but probably not very far from reality. Dieter, is it possible to resize existing partitions via PARTITIONS variable in the config file? What kind of error do you get if you put incorrect values there? Denis.
Re: [arch-general] Good press at distrowatch.com
On Fri 18 Dec 2009 17:54 +0100, Dieter Plaetinck wrote: I agree with Dieter, that the install should be measured by speed and automation -- but long ago I realized that there a whole lot of other people out there that just don't think like me :p Don't misunderstand me. An interactive hold-your-hand-a-bit installation processes is a good thing for many use cases (if implemented correctly). There are many ways to judge installations by. I'm only saying: if one chooses to judge an installation system by the criterion of speed, then (s)he better gets his/her facts right before calling our approach slow[er]. It's probably considered slower because there is a lot of prior knowledge that is required. It may be easier (and faster) for someone who has no computer background to install Ubuntu than to install Arch. With Arch that person would have to do a lot more reading and learning, which would take a lot more time.
Re: [arch-general] Good press at distrowatch.com
On Fri, 18 Dec 2009 13:58:54 -0500 Denis Kobozev d.v.kobo...@gmail.com wrote: Dieter, is it possible to resize existing partitions via PARTITIONS variable in the config file? don't think so. it's meant to make new ones. What kind of error do you get if you put incorrect values there? You'll get an error that partitioning failed. in the interactive procedure you can just retry. for the automatic.. i don't remember. maybe it just aborts. Dieter
Re: [arch-general] New Thunderbird build 3.0-2 installs lightning by default
On 12/18/09, Magnus Therning mag...@therning.org wrote: On Thu, Dec 17, 2009 at 5:28 PM, Javier Vasquez j.e.vasque...@gmail.com wrote: On 12/15/09, Ionut Biru biru.io...@gmail.com wrote: On 12/15/2009 09:19 PM, Arvid Picciani wrote: On 12/15/2009 07:37 AM, Jürgen Hagemann wrote: ... thunderbird-3.0-3 has no gnomeui, no lightning. -- Ionut And is this good? The lightning XPI doesn't work for x86_64, the lightning in AUR doesn't work with 3.0 (I even tried to tweak PKGBUILD myself with no luck), so there's no lightning at all for x86_64 architecture... I can see the logic behind the decision, if lightning (as shipped with TB3) is suggested to be turned off by upstream, then it's prudent to turn it off in the distro's default build too. Irritating for me, yes, but I can live with it. I put up a binary package based on a modified PKGBUILD (actually, the file that needs modifying is mozconfig) at http://therning.org/magnus_arch/thunderbird-3.0-3.1-x86_64.pkg.tar.gz It's what I use and it works for me. If you don't want to use the binary directly I'll be happy to post the source package for you. /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe The change is this one, right? % diff mozconfig.1 mozconfig.2 24d23 ac_add_options --enable-calendar I understand what you're saying. However the effect of following the recommendation is orphaning x86_64 from lightning. What seems an issue to me is not considering calendar integration (whether by add-on, or built-in) as a must for thunderbird (so far such integration for x86_64 is only possible built-in). So I can compile my own thunderbird-lightning package (already did, with the enable option before), but as the issue is that calendar integration is not consider a must for thunderbird, while it is a need for me, perhaps the best approach for me is to drop thunderbird for another e-mail client for which calendar integration is a must... If calendar integration was a must, another option might have been considered: 1.- Drop calendar support for x86_64. (selected option) 2.- Keep calendar support with 3.0 built-in. 3.- Don't update to 3.0 for x86_64 until calendar support is enabled through add-on. Any ways, I won't discuss further since answers indicate people is OK with the decision... Thanks, -- Javier.
