I must have missed the part where the MacOS X kernel was fast. I believe when Miguel de Icaza first compiled Mono on an Apple laptop which was faster than his desktop PC, the compile took almost twice as long (don't have a citation, it was a blog entry some time ago).
Basically, Mach has had severe performance problems especially with things like file I/O, which they are now "fixing" the same way Microsoft did with NT, by moving some servers in kernel.
When exec-shield randomization is enabled, the DSO load addresses are scrambled. What that means is that while you can run arbitrary code, it's not really possible to make any library calls. Have you ever written non-trivial code without the presence of libc? I have, it's not much fun. You have to do everything using direct syscalls into the kernel, which is tricky and limited.
So in short while exec-shield in this case won't prevent the overflow (as it can with ASCII stack based overflows), it does make it harder to do things when you've infiltrated the system.
It's worth noting that the implementation of COM on MacOS X is severely restricted compared to COM on Win32, in particular it's missing almost all of DCOM and OLE automation...
Practically every KDE app has DCOP support.. while under Gnome, very few use Corba, probably due to the real/percieved slowness of it
Actually a good ORB (such as ORBit) walks all over DCOP for RPC speed, the main reason CORBA never took off for desktop scripting is because it's API is a pain in the ass.
That's a bit unfair. What that post actually says is that they are going to move to time based releases rather than functionality based releases, which makes a good deal of sense.
Lotus Notes is not sandboxed, but Notes uses its own rendering engine (not IE) for email which means it's less likely to suffer from random auto-execute holes than Outlook. Notes also has significantly less userbase than Outlook so it's less likely to be targetted by worms.
Having said that, these sort of things are rather crude hacks. The correct solution to security/sandboxing in Wine is the same solution as for native Linux apps, namely locking down the program using the SELinux policy enforcement engine. Currently Wine doesn't integrate with SELinux at all, but it'd not be hard to do if somebody wished to make it a project of theirs.
most of NTDLL, parts of the shell interface, exactly what message orderings/sequences are generated by Windows in certain circumstances, the full TEB layout, that sort of thing...
Those are just the undocumented/poorly documented bits. Then there's a whole ton of extra APIs for which documentation exists, but the APIs are so complex or obscure that hardly anybody understands them. This is especially true of things like the RPC runtime which not many developers use directly, and the more intricate parts of DCOM (which you need to read several books to be completely au fait with).
It's not so much that they are never used, the sheer number of apps out there pretty much guarantees somebody, somewhere will have used any given API.
It's more that in all the apps we've tried to run on Wine, nothing has ever tried to use that feature (new features tend to be easier to add than fixing bugs in existing features). And yes, there are a whole ton of calls that simply aren't implemented because even large, complex apps like DreamWeaver, MS Office etc don't use them.
Exactly - let's not forget the various different UI ideas Gnome and KDE have played with them abandoned because Apple specifically held patents on them. Simply the presence of the patent alone is enough to make it impossible to use a technique simply because Apple could at any point turn around and start charging money from it (oh, and they are quite happy to charge free software companies license fees btw)
That's hardly GNOMEs problem/fault. There was no guaranteed way to launch the browser before, as the distro is quite free to switch off desktop icons if they so wish.
How is an item in a context menu more promenant than a dedicated icon on the default panel, which looks like a filing cabinet?
And look - if you don't like it, just open up some browser windows and leave them there. It just isn't a big deal. The number of people who absolutely must have desktop icons open up browser windows and flip their lid if that's not the case just isn't that large.
They are until you drag in half a ton of the Mac API in order to start an app.
It's entirely possible to make a fast, responsive music playing application for Windows. Apple did not. That says everything about Apples software engineering and nothing about respective hardware, basically...
There aren't _that_ many settings. You could just say "I want to tweak Nautilus" fire up gconf-editor and look in the Nautilus folder. The keys are mostly documented, right? I have to admit, I tweak my environment just as much as the next guy, and I've yet to search google for a gconf setting...
Basically if you click a folder on the desktop, it'll be spatial. If you click the "Browse Filesystem" icon in the menu or panel, it'll be the old style browser. You can also enter browser mode at any point by right clicking a folder and choosing "Browse Folder".
I think the guys point was that Nick was so blinded by his dislike of Gnome he failed to spot the multitude of ways to get what he wanted. I think on startup Gnome could have had a huge blaring siren and a big red arrow pointing to the relevant icon saying "Click here for a file system browser!!!" and Nick still wouldn't have noticed.
In other words he had an agenda and wasn't going to let little things like facts get in his way.
common-sense dictates that the new mode should be OFF by default. To do otherwise will scare users who were accustomed to the existing behavior. (Or at minimum, the checkbox to "Act like the older version" should be prominently placed, such as an option at install)
Ugh, then you end up with idiocy like the Gaim "Old style nick completion" setting which never made any difference to how nick completion worked as far as I could tell. It also has the most meaningless name in existance - I only started using Gaim after it had been ported to GTK2 and the style had changed.
Presumably there was some difference, but having a setting like that in the GUI is rarely justified. If you keep doing it you end up with a settings window full of stuff meaningless/pointless to new users. Either the new way is better, or it isn't, and if you aren't sure then you probably need a clearer idea of what your goal is and where you're heading anyway.
The Gnome developers never argued that configurability was inherantly bad, they argued that Gnome 1.4 had a whole ton of bad prefs. Pretty much everybody has recognized that this was (and in some cases still is) a problem in many open source projects. That includes not just Gnome but KDE and Wine as well - all these projects have efforts to clean up their UI.
What is a bad pref?
A bad pref is something that:
Expects the user to have knowledge they probably don't. The most extreme example of this is the PerfectGraphics setting in Wine, for which nobody actually knows what effect it has - not even the developers! Does it make things look different? When should it be on, and when should it be off? It's not documented and nobody seems to know. It's a bad pref. It should almost certainly be removed or at least banished to the registry.
KDE has some pretty stupid ones too. Check out the "Minimize memory usage" checkbox in Konqueror. Maybe it's gone now but it's been there for a looooong time. Just ponder what this pref is asking the user for a moment. When would they not want to minimize memory usage? If you uncheck it, how much more memory would be used? What is it being used for? Being able to usefully set this pref requires way more knowledge than 99% of people actually have, and meanwhile it's adding to the combinatorial complexity of the software.
Dumb prefs. Gnome 1.4 had an option to toggle the ellipses on menus (or was it buttons?), so if you didn't like "File..." you could have just "File". Lovely. Except - who actually used it? Did anybody? Nobody complained when it was removed, so presumably not. It was a dumb pref, configuring something so minute and small that the cost of the setting was not worth the gain.
Easy to screw up prefs. Klipper has an option to break the clipboard by mangling the PRIMARY and CLIPBOARD selections together. It's a relic of the days when Qt was buggy and some people got used to it, then when Qt was fixed people found their old habits no longer worked. It takes all of about 10 minutes to adjust to having a working clipboard (and before it was fixed this was the number one complaint w.r.t the Linux clipboard being broke), but instead a pref was added to keep the broken behaviour.
Users experiment and fiddle with things. If you don't know what it does, enabling this pref will seem to be harmless, until a week later you are trying to figure out why you can't paste into the URL bar anymore.
This pref is especially insidious because it provides an excuse to keep around the pointless clear-this-edit buttons that so mystified me when I started using Linux (well, KDE). What are they there for? Why not just select the text and delete like in Windows? Why do only some edits have them?
In short, I've never seen any research that makes such a vague and sweeping statement like "configurability (in an ui) is always good as long as the defaults are sensibly chosen". I have seen users confused, and I've been myself confused, by bizarre, broken or bad prefs that simply do not belong in a well designed graphical user interface. If you could cite this research, I would be grateful.
I went to that site - maybe it's because my browser doesn't identify as IE but looking at the source doesn't reveal anything that could trigger bugs in IE. There are no scripts that I can see except a harmless onclick to open a popup when going to a partner site. What code actually causes the problems?
On this subject, I've heard Wine is seriously considering GNU Arch. Anyone care to comment on this?
Sure. I set up the prototype gateway. Julliard is keen, but it's a major change you know, not something you do overnight. And to be frank CVS works OK for most of the developers, it'd be primarily useful for those of us who do a lot of hacking, like the D3D developers or the CodeWeavers gang (we have to maintain multiple trees for crossover and it's a pain in the ass).
I haven't used BitKeeper (I can't as I have done a couple of trivial bugfixes in arch, duh), but arch works pretty well for me. It could be a bit faster, but I like its transparent design and responsive and friendly community.
The fact that it's actually used outside of one project/domain (unlike BitKeeper) also helps as there's a wider pool of experience to tap into.
Having said that, while it's maturing fast it still has an evil UI (no Tom wrappers are NOT an acceptable solution for that), and lacks some important features like being able to turn a changeset into a flat text file and then email it in one command. If you're willing to do some scripting arch is the most powerful SCM I've ever seen, but it could always be better.
Finally it's a bit misleading to say that it was BitKeeper that made Linus 10x more productive. Before BK they didn't use any source control at all, and all patches were sent either in private email or onto lkml. It's not surprising that using source control improved things!
For comparison, Alexandre Julliard who maintains Wine processes approximately 100 checkins a week, so that's about 14 a day. We use CVS with a single committer. Given that Alexandre actually codes a lot as well, I think it's pretty clear that Linus' "productivity boost" more to do with being able to work full time and having a decent project structure (we all send patches to a dedicated mailing list for instance and we don't have a ton of "lietenant" trees) than anything magical about BitKeeper.
I'd be surprised if this makes the interview given that CrossOver 3 is OUT TOMORROW and yes Microsoft Money does start and appears to be usable. We only got Money starting at the last minute though, so it might still be rather buggy - why not download the demo when available and find out?
Slashdot Mirror
Basically, Mach has had severe performance problems especially with things like file I/O, which they are now "fixing" the same way Microsoft did with NT, by moving some servers in kernel.
So in short while exec-shield in this case won't prevent the overflow (as it can with ASCII stack based overflows), it does make it harder to do things when you've infiltrated the system.
It's worth noting that the implementation of COM on MacOS X is severely restricted compared to COM on Win32, in particular it's missing almost all of DCOM and OLE automation ...
Actually a good ORB (such as ORBit) walks all over DCOP for RPC speed, the main reason CORBA never took off for desktop scripting is because it's API is a pain in the ass.
OK, I should have read the entire thread before posting. I eat my words. That is indeed incredibly silly.
That's a bit unfair. What that post actually says is that they are going to move to time based releases rather than functionality based releases, which makes a good deal of sense.
The registry was developed for OLE, and existed in Windows 3.1 though it wasn't used as a global config database until WIndows 95, iirc.
Having said that, these sort of things are rather crude hacks. The correct solution to security/sandboxing in Wine is the same solution as for native Linux apps, namely locking down the program using the SELinux policy enforcement engine. Currently Wine doesn't integrate with SELinux at all, but it'd not be hard to do if somebody wished to make it a project of theirs.
Those are just the undocumented/poorly documented bits. Then there's a whole ton of extra APIs for which documentation exists, but the APIs are so complex or obscure that hardly anybody understands them. This is especially true of things like the RPC runtime which not many developers use directly, and the more intricate parts of DCOM (which you need to read several books to be completely au fait with).
It's more that in all the apps we've tried to run on Wine, nothing has ever tried to use that feature (new features tend to be easier to add than fixing bugs in existing features). And yes, there are a whole ton of calls that simply aren't implemented because even large, complex apps like DreamWeaver, MS Office etc don't use them.
Exactly - let's not forget the various different UI ideas Gnome and KDE have played with them abandoned because Apple specifically held patents on them. Simply the presence of the patent alone is enough to make it impossible to use a technique simply because Apple could at any point turn around and start charging money from it (oh, and they are quite happy to charge free software companies license fees btw)
That's hardly GNOMEs problem/fault. There was no guaranteed way to launch the browser before, as the distro is quite free to switch off desktop icons if they so wish.
So in other words you lose all the most valuable stuff, but the system will continue working OK anyway.
And look - if you don't like it, just open up some browser windows and leave them there. It just isn't a big deal. The number of people who absolutely must have desktop icons open up browser windows and flip their lid if that's not the case just isn't that large.
It's entirely possible to make a fast, responsive music playing application for Windows. Apple did not. That says everything about Apples software engineering and nothing about respective hardware, basically ...
There aren't _that_ many settings. You could just say "I want to tweak Nautilus" fire up gconf-editor and look in the Nautilus folder. The keys are mostly documented, right? I have to admit, I tweak my environment just as much as the next guy, and I've yet to search google for a gconf setting ...
Look, I really suggest you use it first ...
This really does seem to be a storm in a teacup.
In other words he had an agenda and wasn't going to let little things like facts get in his way.
Ugh, then you end up with idiocy like the Gaim "Old style nick completion" setting which never made any difference to how nick completion worked as far as I could tell. It also has the most meaningless name in existance - I only started using Gaim after it had been ported to GTK2 and the style had changed.
Presumably there was some difference, but having a setting like that in the GUI is rarely justified. If you keep doing it you end up with a settings window full of stuff meaningless/pointless to new users. Either the new way is better, or it isn't, and if you aren't sure then you probably need a clearer idea of what your goal is and where you're heading anyway.
What is a bad pref?
A bad pref is something that:
KDE has some pretty stupid ones too. Check out the "Minimize memory usage" checkbox in Konqueror. Maybe it's gone now but it's been there for a looooong time. Just ponder what this pref is asking the user for a moment. When would they not want to minimize memory usage? If you uncheck it, how much more memory would be used? What is it being used for? Being able to usefully set this pref requires way more knowledge than 99% of people actually have, and meanwhile it's adding to the combinatorial complexity of the software.
Users experiment and fiddle with things. If you don't know what it does, enabling this pref will seem to be harmless, until a week later you are trying to figure out why you can't paste into the URL bar anymore.
This pref is especially insidious because it provides an excuse to keep around the pointless clear-this-edit buttons that so mystified me when I started using Linux (well, KDE). What are they there for? Why not just select the text and delete like in Windows? Why do only some edits have them?
In short, I've never seen any research that makes such a vague and sweeping statement like "configurability (in an ui) is always good as long as the defaults are sensibly chosen". I have seen users confused, and I've been myself confused, by bizarre, broken or bad prefs that simply do not belong in a well designed graphical user interface. If you could cite this research, I would be grateful.
I went to that site - maybe it's because my browser doesn't identify as IE but looking at the source doesn't reveal anything that could trigger bugs in IE. There are no scripts that I can see except a harmless onclick to open a popup when going to a partner site. What code actually causes the problems?
Sure. I set up the prototype gateway. Julliard is keen, but it's a major change you know, not something you do overnight. And to be frank CVS works OK for most of the developers, it'd be primarily useful for those of us who do a lot of hacking, like the D3D developers or the CodeWeavers gang (we have to maintain multiple trees for crossover and it's a pain in the ass).
The fact that it's actually used outside of one project/domain (unlike BitKeeper) also helps as there's a wider pool of experience to tap into.
Having said that, while it's maturing fast it still has an evil UI (no Tom wrappers are NOT an acceptable solution for that), and lacks some important features like being able to turn a changeset into a flat text file and then email it in one command. If you're willing to do some scripting arch is the most powerful SCM I've ever seen, but it could always be better.
Finally it's a bit misleading to say that it was BitKeeper that made Linus 10x more productive. Before BK they didn't use any source control at all, and all patches were sent either in private email or onto lkml. It's not surprising that using source control improved things!
For comparison, Alexandre Julliard who maintains Wine processes approximately 100 checkins a week, so that's about 14 a day. We use CVS with a single committer. Given that Alexandre actually codes a lot as well, I think it's pretty clear that Linus' "productivity boost" more to do with being able to work full time and having a decent project structure (we all send patches to a dedicated mailing list for instance and we don't have a ton of "lietenant" trees) than anything magical about BitKeeper.
I'd be surprised if this makes the interview given that CrossOver 3 is OUT TOMORROW and yes Microsoft Money does start and appears to be usable. We only got Money starting at the last minute though, so it might still be rather buggy - why not download the demo when available and find out?