Gecko isn't multithreaded, but instead it uses a timer which periodically triggers so called incremental reflow. It boils down to much the same thing though.
It's just standard Microsoftie-speak. You get used to it after a bit. They talk a lot about "stacks" and tend to start sentances with the word "so" quite a bit.
Anyway, he's saying that Linux is fragmenting/fragmented. This is true to a certain extent but I think the general trend right now is to try and reduce needless differences. For instance while Red Hat still heavily patch their kernels, Fedora is trying to reduce the number of downstream patches to a minimum. Likewise with desktop infrastructure, a lot more is being done upstream these days.
Re:hope they finally got rid of some annoyances ..
on
GNOME 2.8 Released
·
· Score: 1
Dunno if that was meant to be a joke, but if not then you seriously missed what I was talking about. And yes, I am a developer...
Yeah, it can be a pain, but to be fair Windows shares part of the blame for this as well. Last time I tried to use a Windows shared printer, it wouldn't appear in the Fedora "select your printer" dialog... a bit of poking around revealed that it didn't appear in another Windows machine as well despite being shared and there being apparently nothing wrong. Windows file and printer sharing has always been awful, I've wasted many hours trying to get Windows 98 machines to talk to XP and vice-versa - given that it doesn't even work reliably between Windows machines it doesn't surprise me in the slightest that Linux has issues as well.
The good news is that ZeroConf is being integrated into Linux quite rapidly now that Apples sucky code has been abandoned and Howl became available. Apparently quite a few modern printers support it natively so now maybe Windows printer sharing can be at least partially bypassed in some larger networks.
Nope, not really. MFC is totally dependent on Win32, it exposes details all over the place like the message passing model, window handles and so on. It's also a disgustingly ugly API.
I'd love to know how this "porting and migration center" is going to deal with all the desktop software that isn't as easy to port as UNIX server software is. It's not even like OpenOffice can deal with all MS Office documents, in particular the ones where people abuse Excel as a database, have MS Access databases lying around, write VBScript apps in Word etc.
Well, not really. It's still a huge leap. Then you have the problem that wxWindows apps don't really feel native on any platform, which makes it a suboptimal solution. If you're going to port an app IMHO you should do it properly and get native UI in there (GTK or Qt) and maybe leave the backend to Winelib until you've got it all ported over to platform abstractions that work, unlike widget toolkit abstractions.
You do have the same problem, it just manifests itself in a different way. It just shows up as having to use old software, or broken packages.
Compiling all your software isn't really a useful solution. How many Gentoo users compile not only gnome-terminal themselves, but the entirety of OpenOffice (a 24 hour compile on some systems)? It doesn't really scale. Good support for binaries is really essential.
D is a lovely, beautiful language that never surprises me and does exactly what I mean - attributes I value highly in a language.
Unfortunately it's also very new and rather immature. While a D frontend for gcc does exist it lags behind the official spec (which is itself incomplete). Also the D standard library is rather poor. It's not "safe" in the sense that Java is, because you can still use pointers but that is in turn its greatest strength : C interop is the easiest of any language. Easier than Java, easier than C#, maybe only Python with Pyrex comes close.
Great, great language. I can't wait for it to mature.
Yeah, indeed. If you look at some of the more serious ones they're actually insecure by design (things like the disk:// URL and auto-loaded URI handlers) rather than simple overflows. That's the sort of ActiveX debacle that Microsoft get slated for all the time, but when Apple does it the silence is deafening.
This is a design fault or feature of the X protocol, depending on your point of view. Clients can "lock" the server, which means it'll only pay attention to protocol requests from that client. You're only supposed to lock the server for short periods of time, for instance whilst playing a fast animation which affects the whole screen (so you don't want other apps drawing to it).
Unfortunately if the app hangs while the server is locked, your whole system freezes. You can get out of it by killing the app which holds the lock thereby releasing it, but this is I think beyond the abilities of most users (you have to know which app to kill, obviously...)
Solutions to this were discussed on the xorg list recently. One possibility is to allow the WM to ping the app in the same way it can currently to check if it's hung or not and pop up a "This app has stopped responding" dialog. But that'd require an extension to the X protocol to allow priviledged clients to ignore the server lock.
OK, so it was a bit over the top, but the guy has a point. People are defending Gates on the grounds that "oh well his company only broke the law multiple times, his execs only lied under oath and forged evidence, he only set out to crush his competitors using immoral means, etc which aren't REALLY bad even though they're illegal because LOOK AT THE TERRORISTS".
That's a pretty crap defense. So the guy is giving away his ill-gotten gains. Great. Wake me up when he's learned respect for the law as well. Until then, you fall into one of two camps: you either respect the will of society or you don't. The fact that the "don't" camp also contains drug dealers and terrorists doesn't change anything.
Sorry dude. Things that are different merely through being apart don't encourage competition, they encourage lockin. That's why we have standards in the first place. Taking your attitude we shouldn't have any web standards because that would mean "borg-like compliance between web sites" and "if you want consistency you should use AOL". The world decided that was a bad approach a long time ago.
By the way, putting trite slogans at the end of a post doesn't make it any more valid or insightful.
Re:hope they finally got rid of some annoyances ..
on
GNOME 2.8 Released
·
· Score: 1
Windows != more resources. Constructing a window in X is a lightweight, fast operation. Yes it uses some resources but constructing and laying out a complex toolbar with embedded edit boxes, a tree view, a spinner, a zoom control etc etc *does* take time. A spatial window just has the icon view, a menu bar and a status bar. Much simpler.
Re:hope they finally got rid of some annoyances ..
on
GNOME 2.8 Released
·
· Score: 2, Informative
Because the GUI is simpler, and because it's the default it's more heavily optimized.
Constructing and rendering a GUI is surprisingly intensive, especially with modern toolkits that support complex layout and text internationalization.
Yes, it is a nasty problem. I won't go into the gory details but the core of the problem is this.
A basic unit of currency in the Linux world is the distribution, as you have discovered. A distribution is essentially just a collection of packages which are, in turn, just compiled versions of (mostly) upstream sources. The thing that makes a distro what it is are the customizations made to the package sources and occasionally packages unique to the distro. All the big distros (ie the ones that matter) are fully open source though so technology which shows up in one pretty quickly migrates upstream somewhere, and then back down again to the other distributions.
That leaves the customizations made, and what exact packages are included by default. This is where problems start to appear.
The traditional solution taken to things that don't really fit into any obvious upstream project is for each distribution to roll their own code. In the past this has happened with menus, hardware detection/pluggability, GUI configuration tools, bootup scripts, and installers. There are others I probably forgot.
In the case of menus, KDE and GNOME used different systems so distributions, not wanting to do a million different files in each package for each individual desktop and window manager each came up with their own solution. Debian has some custom system that Mandrake then adopted as well, SuSE only really supported KDE anyway, Red Hat 8 introduced this thing called "vFolders" which was an aborted attempt at a desktop-neutral standard and was one of the first things specced out at freedesktop.org. Later vFolders was shown to have serious problems and was abandoned but not before being integrated upstream into GNOME (but not KDE!). Red Hat abandoned vFolders in Fedora Core 2 but upstream GNOME did not do the same. So now we're still at this point where while everybody has agreed on a standard, it's not actually implemented uniformly at all.
D'oh. What a mess. This sort of thing has been repeated over and over, whenever something didn't really fit into any upstream project. As time goes by more and more is being sucked upstream into projects like freedesktop.org... hardware detection is now being handled by HAL (though there is some internal resistance from SuSE who have a.... surprise.... custom solution called suseplugger), network config scripts are destined for replacement by NetworkManager if Red Hat have their way, etc etc.
So... the random hacks different distros use to tie these disparate pieces of code together are gradually disappearing. This is good. It does, however, leave the second problem:
What packages are included? This is a bigger issue than you may think. There really is no such thing as the "Linux platform". There are small, mostly stable subsets like GNOME and KDE but this is the exception rather than the norm. Specialised libraries like pcre, OpenSSL, libpng and so on which aren't affiliated with any central project policies tend to break backwards compatibility all the time - often it could have been avoided. Each time this happens, you need a new parallel installable package that other packages can depend upon.
Typically, distributions are recompiled entirely on each new revision. So let's say that libfoo breaks backwards compatibility. The new version is included in the new distribution version, all the packages are recompiled or patched to use it, and now the old version isn't included any more.
This has the unfortunate side effect that you cannot make any assumptions about what features are available on any given Linux system beyond some really basic base libraries like libc, Xlibs etc.
Worse, even projects like GNOME and GTK+ often refuse to avoid breaking applications if they deem them "buggy" or "broken", which tends to have a very wide definition. So, the net result
Well, that problem is a combination of things. Firstly if you used the official Firefox installer, then this offers no integration into the host system at all. None. Not even menu items.
If you install packages from your distro then you will *probably* get menu items. This is assuming that there is an up-to-date and correct package for your distro of course. If you install software from source, you may need to set the prefix to be/usr to get menu items, or change the configuration of your system (if you do it's a bug in the distro but a very common one).
It's not really a GNOME issue. It's a generic Linux issue, which will take some years to solve correctly I'm afraid...
Re:hope they finally got rid of some annoyances ..
on
GNOME 2.8 Released
·
· Score: 3, Informative
- gui option to switch off spatial nautilus
Yes
- improved gdm which doesn't cause random system hangs on logout (with a dual display GeForce setup)
Never heard of that before. Check bugzilla
- faster nautilus
If you use spatial nautilus it's extremely fast. If you don't, then it's not so fast. Pick your poison.
Haha, yeah, I remember Raptor. It was little more than a 5 minute VC++ hacked up embedder, iirc.
Then there was that horrid Bluesomething theme, whos name I forget. Designed to look like NetCenter. Ugh!
It was fun though. I wrote a feature for good old Moz but it was never checked in, ironically due to security concerns (we addressed them but then it bitrotted) - sigh.
Rememeber, the browsers CHROME is efectively generated from XML, and often uses JavaScript to bind the components together
Yeah but some IE dialogs are actually generated from HTML. The "install components" dialog is for instance - as is the about box. Little known but true...
If you can access Python and upload files to the shell account you can still run any program you like on a noexec mount, through virtue of userland exec. In fact there are a million ways to do it. There really is no good way to enforce noexec on any UNIX.
Yes obviously we realise that, but Gecko does implement some IE compatibility these days, and some apps just use it as a generic web browser. So it's better than nothing.
Long term plan is (I think) to work with the Gecko guys and implement all the IE technologies in Gecko, optional at build time. If they don't want them, it'll be forked.
The first is an interface-compatible Gecko baesd replacement for MSHTML. This is good, because we can use it in the Wine project as a placeholder until a real MSHTML clone is developed.
The second is ActiveX compatibility for Gecko. This is also good though it should probably be off by default. Quite a lot of corporate intranets/web apps require ActiveX so supporting it can get Firefox/Mozilla into these places.
Slashdot Mirror
Gecko isn't multithreaded, but instead it uses a timer which periodically triggers so called incremental reflow. It boils down to much the same thing though.
Anyway, he's saying that Linux is fragmenting/fragmented. This is true to a certain extent but I think the general trend right now is to try and reduce needless differences. For instance while Red Hat still heavily patch their kernels, Fedora is trying to reduce the number of downstream patches to a minimum. Likewise with desktop infrastructure, a lot more is being done upstream these days.
Dunno if that was meant to be a joke, but if not then you seriously missed what I was talking about. And yes, I am a developer ...
The good news is that ZeroConf is being integrated into Linux quite rapidly now that Apples sucky code has been abandoned and Howl became available. Apparently quite a few modern printers support it natively so now maybe Windows printer sharing can be at least partially bypassed in some larger networks.
Uh, I think when done "well" DRM doesn't bother most consumers at all. It's only people who use "alt tech" like Linux who suffer and kick up a fuss.
You can run both Notes 6.5.1 and Photoshop using CrossOver Office.
I'd love to know how this "porting and migration center" is going to deal with all the desktop software that isn't as easy to port as UNIX server software is. It's not even like OpenOffice can deal with all MS Office documents, in particular the ones where people abuse Excel as a database, have MS Access databases lying around, write VBScript apps in Word etc.
Well, not really. It's still a huge leap. Then you have the problem that wxWindows apps don't really feel native on any platform, which makes it a suboptimal solution. If you're going to port an app IMHO you should do it properly and get native UI in there (GTK or Qt) and maybe leave the backend to Winelib until you've got it all ported over to platform abstractions that work, unlike widget toolkit abstractions.
Compiling all your software isn't really a useful solution. How many Gentoo users compile not only gnome-terminal themselves, but the entirety of OpenOffice (a 24 hour compile on some systems)? It doesn't really scale. Good support for binaries is really essential.
Unfortunately it's also very new and rather immature. While a D frontend for gcc does exist it lags behind the official spec (which is itself incomplete). Also the D standard library is rather poor. It's not "safe" in the sense that Java is, because you can still use pointers but that is in turn its greatest strength : C interop is the easiest of any language. Easier than Java, easier than C#, maybe only Python with Pyrex comes close.
Great, great language. I can't wait for it to mature.
Yeah, indeed. If you look at some of the more serious ones they're actually insecure by design (things like the disk:// URL and auto-loaded URI handlers) rather than simple overflows. That's the sort of ActiveX debacle that Microsoft get slated for all the time, but when Apple does it the silence is deafening.
Unfortunately if the app hangs while the server is locked, your whole system freezes. You can get out of it by killing the app which holds the lock thereby releasing it, but this is I think beyond the abilities of most users (you have to know which app to kill, obviously ...)
Solutions to this were discussed on the xorg list recently. One possibility is to allow the WM to ping the app in the same way it can currently to check if it's hung or not and pop up a "This app has stopped responding" dialog. But that'd require an extension to the X protocol to allow priviledged clients to ignore the server lock.
That's a pretty crap defense. So the guy is giving away his ill-gotten gains. Great. Wake me up when he's learned respect for the law as well. Until then, you fall into one of two camps: you either respect the will of society or you don't. The fact that the "don't" camp also contains drug dealers and terrorists doesn't change anything.
No, GNOME in Fedora Core 2 is, upstream is still stuck on the old vFolders spec.
By the way, putting trite slogans at the end of a post doesn't make it any more valid or insightful.
Windows != more resources. Constructing a window in X is a lightweight, fast operation. Yes it uses some resources but constructing and laying out a complex toolbar with embedded edit boxes, a tree view, a spinner, a zoom control etc etc *does* take time. A spatial window just has the icon view, a menu bar and a status bar. Much simpler.
Constructing and rendering a GUI is surprisingly intensive, especially with modern toolkits that support complex layout and text internationalization.
A basic unit of currency in the Linux world is the distribution, as you have discovered. A distribution is essentially just a collection of packages which are, in turn, just compiled versions of (mostly) upstream sources. The thing that makes a distro what it is are the customizations made to the package sources and occasionally packages unique to the distro. All the big distros (ie the ones that matter) are fully open source though so technology which shows up in one pretty quickly migrates upstream somewhere, and then back down again to the other distributions.
That leaves the customizations made, and what exact packages are included by default. This is where problems start to appear.
The traditional solution taken to things that don't really fit into any obvious upstream project is for each distribution to roll their own code. In the past this has happened with menus, hardware detection/pluggability, GUI configuration tools, bootup scripts, and installers. There are others I probably forgot.
In the case of menus, KDE and GNOME used different systems so distributions, not wanting to do a million different files in each package for each individual desktop and window manager each came up with their own solution. Debian has some custom system that Mandrake then adopted as well, SuSE only really supported KDE anyway, Red Hat 8 introduced this thing called "vFolders" which was an aborted attempt at a desktop-neutral standard and was one of the first things specced out at freedesktop.org. Later vFolders was shown to have serious problems and was abandoned but not before being integrated upstream into GNOME (but not KDE!). Red Hat abandoned vFolders in Fedora Core 2 but upstream GNOME did not do the same. So now we're still at this point where while everybody has agreed on a standard, it's not actually implemented uniformly at all.
D'oh. What a mess. This sort of thing has been repeated over and over, whenever something didn't really fit into any upstream project. As time goes by more and more is being sucked upstream into projects like freedesktop.org ... hardware detection is now being handled by HAL (though there is some internal resistance from SuSE who have a .... surprise .... custom solution called suseplugger), network config scripts are destined for replacement by NetworkManager if Red Hat have their way, etc etc.
So ... the random hacks different distros use to tie these disparate pieces of code together are gradually disappearing. This is good. It does, however, leave the second problem:
What packages are included? This is a bigger issue than you may think. There really is no such thing as the "Linux platform". There are small, mostly stable subsets like GNOME and KDE but this is the exception rather than the norm. Specialised libraries like pcre, OpenSSL, libpng and so on which aren't affiliated with any central project policies tend to break backwards compatibility all the time - often it could have been avoided. Each time this happens, you need a new parallel installable package that other packages can depend upon.
Typically, distributions are recompiled entirely on each new revision. So let's say that libfoo breaks backwards compatibility. The new version is included in the new distribution version, all the packages are recompiled or patched to use it, and now the old version isn't included any more.
This has the unfortunate side effect that you cannot make any assumptions about what features are available on any given Linux system beyond some really basic base libraries like libc, Xlibs etc.
Worse, even projects like GNOME and GTK+ often refuse to avoid breaking applications if they deem them "buggy" or "broken", which tends to have a very wide definition. So, the net result
If you install packages from your distro then you will *probably* get menu items. This is assuming that there is an up-to-date and correct package for your distro of course. If you install software from source, you may need to set the prefix to be /usr to get menu items, or change the configuration of your system (if you do it's a bug in the distro but a very common one).
It's not really a GNOME issue. It's a generic Linux issue, which will take some years to solve correctly I'm afraid ...
Yes
- improved gdm which doesn't cause random system hangs on logout (with a dual display GeForce setup)
Never heard of that before. Check bugzilla
- faster nautilus
If you use spatial nautilus it's extremely fast. If you don't, then it's not so fast. Pick your poison.
- fixed constantly non-functional (without necessary tweaking) file preview (audio and video)
It always worked for me out of the box on Fedora, though you may have to enable it in the preferences for remote mounts.
Then there was that horrid Bluesomething theme, whos name I forget. Designed to look like NetCenter. Ugh!
It was fun though. I wrote a feature for good old Moz but it was never checked in, ironically due to security concerns (we addressed them but then it bitrotted) - sigh.
Rememeber, the browsers CHROME is efectively generated from XML, and often uses JavaScript to bind the components together
Yeah but some IE dialogs are actually generated from HTML. The "install components" dialog is for instance - as is the about box. Little known but true ...
If you can access Python and upload files to the shell account you can still run any program you like on a noexec mount, through virtue of userland exec. In fact there are a million ways to do it. There really is no good way to enforce noexec on any UNIX.
Any program can ask for the root password and use it. How do you think autopackage uses a custom su frontend?
Long term plan is (I think) to work with the Gecko guys and implement all the IE technologies in Gecko, optional at build time. If they don't want them, it'll be forked.
The first is an interface-compatible Gecko baesd replacement for MSHTML. This is good, because we can use it in the Wine project as a placeholder until a real MSHTML clone is developed.
The second is ActiveX compatibility for Gecko. This is also good though it should probably be off by default. Quite a lot of corporate intranets/web apps require ActiveX so supporting it can get Firefox/Mozilla into these places.