I'm glad you think it's straightforward. The months it took to develop the SHM wineserver were just because TransGaming like making things hard for themselves I guess. It had nothing to do with the fact that while Alice is like the Quake engine it actually is not Quake but rather an entirely different game. In the case of Alice, it was its mutex-swapping behaviour which caused the development of the SHM wineserver to speed up such pathological speed cases.
Originally I thought the CLR would be great, as it's basically language interop the Right Way - as long as you remember that language interop always involves compromises, you're good.
But it seems that the dream of great language interop has not been reached even with.NET - look at the work Nat+Trow are doing with Beagle/Dashboard. Rather than use the.NET CLR tools to reuse the Lucene search engine (written in Java), they forked it and rewrote it in C# - why?!
I see this even more. Interop is great in theory, but lacking in practice. See how they started out by using libxml/libxslt to implement the System.Xml APIs and then abandoned that and wrote their own in C#, partly because C interop was not good enough/high performance enough.
To be frank, I think Mono isn't going to unify anything. People will still code in C, C++, Python, C# and so on, and they will all be running in their "native" forms. So we just have yet another platform that needs to be bridged for useful work to get done (via some kind of COM-like technology).
The whole point about these exploits is that they are silent and unstoppable - IE does *not* ask you to install them because they get in via various exploits like ByteVerify/HTMLHelp and so on.
Firefox is actively developed, which helps enormously. The IE team are just getting back together.
Still, Firefox could be better. For instance XBL bindings should not be allowed in user style sheets.
If anything Firefox is more hackable than IE, as if you can get write access to its directory then you can basically rewrite its UI logic as you see fit.
Yep, exactly. More importantly SELinux lets you set programs as suid root and then sandbox them down to less than root, so we can start doing away with the stupid root password prompts that pop up all the time (in a typical home user scenario). SELinux will also improve security on servers.
Don't be fooled though - SELinux is great but it's purely damage control. It's only useful once your system has already been compromised.
Actually, running as non-root provides almost no protection against viruses as most things they want to do can be done as user (send email, modify webpages using CSS/XBL, hijack programs etc). Root is a good security system on a server, but the security challenges facing the desktop are entirely different.
I'm talking about an open source equivalent to things like Norton AntiVirus - at some point, at some time desktop Linux will be hit by viruses/spyware/other undesireables. Current security technologies are purely focussed upon preventation and none upon cure.
Yes I know there are no viruses today. That's what wargaming is for. Be prepared. It's the only way.
So write them for Linux instead - integration into the OS there is the highest honour as it will be your work used by millions. No, you won't make money off it directly, but there was never much money in shareware anyway. You can make money indirectly - people can see your skill firsthand. I've already had work offers thanks to my volunteer open source project and due to my involvement with another (Wine), now have a job working on free software that I'm very happy with.
KParts is little more than a glorified C++ classloader, it's definitely NOT an equivalent to OLE feature-wise. If you think it is, you need to learn more about OLE....
Visual Studio has working precompiled headers out of the box.
This is now true of GCC as well.
Visual Studio has a good incremental build system (and fix-and-debug support).
That's not related to the compiler, that's just a function of the IDE. I sometimes use flymake mode in emacs to achieve a similar effect. It's less cool than the VS equivalent but does work in a lot more situations.
GDB C++ support is a wreck; it has trouble demangling symbols, it chokes on template instantiations, and it gets line-number confused.
I don't know about that but I've never heard of such problems nor encountered them myself...
GDB thread support is a wreck.
That's no longer true on a modern distro
Visual Studio generates better X86 code than GCC.
That's true. Flip side is that VS only generates X86 code, which isn't always what you want.
The Visual Studio UI canvas is better integrated with the compiler than Glade is with GCC.
Again you are confusing the compiler with the IDE. In fact, while the Glade/environment separation is sometimes annoying it's mostly useful. It means you can use whatever editor/coding environment you want unlike with Visual Studio where if you want to use the VS form designer you must use the VS editor, VS build system etc etc. Separate tools do not necessarily imply lack of integration even if in this case Glade is rather lacking.
* Disable XPInstall entirely. You can install XPIs by loading from the file manager, in place installation is convenient but dangerous. It's already been abused by scumware authors despite Firefoxes minimal market share.
* Compile Moz/FF with ProPolice or similar stack guard technologies, if it's possible.
* Implement opt-out URL blacklisting with the updated [signed] list being retrieved from DNS caches (or something similar to reduce load)
* Audit the code and perform wargaming (ie have organized hack events where people try and break Mozilla security), perhaps offer prizes for discovering holes in it.
I want us to start doing some of these things for Linux in the near future, but trialling these sort of techniques on Mozilla is a good plan,
How did you figure that one out? At least, according to eWeek this is some kind of buffer overflow or something, the image can force IE to run arbitrary code which then (surprise surprise) contacts Russian and US trojan servers.
I don't know how to do it as the page loads but for performance you probably want to edit the page after it's loaded, so at least the user can see the images etc.
Basically: create an XPCOM component in C++ (if JavaScript or Python are too slow for you) which performs the computation. Mark your XPCOM interface as scriptable, use the typelib compiler to expose it to javascript then pass in the browser DOM so it can be edited by your component. Then write an extension to catch "page loaded" and pass the DOM to the loaded XPCOM component. I think that should work.
AIM isn't really cross platform. It works because of lots of reverse engineering on the OSCAR protocol. It could change at any time, indeed, AOL have blocked/firewalled jabber servers in the past.
They don't have to release their software. All they have to do is all agree to use an open, standardised protocol like Jabber/XMPP or something else, and then stick to it. They could even keep ads in their own clients, just prevent users logging into their accounts with 3rd party clients but still allow 3rd party clients to connect via other servers/accounts. This is what Hotmail does, for instance.
As it is, the IM companies are all too reliant upon network effects sucking more users in to compete effectively on their service quality instead of how many users they have.
Well, the reason people get upset about this sort of thing is precisely because IM services are not normal free services, they are platforms which ruthlessly exploit network effects to gain profit.
As it happens, I do not know anybody who uses Y!IM so I do not care about this. The story would be very different if it was MSN Messenger. I use Linux, my job requires it in fact, and of course there is no official MSN client for Linux and probably never will be. I would LOVE for all my friends to use Jabber, but I tried many years ago to persuade said friends to use Jabber instead of MSN and to be frank MSN beat the snot out of Jabber through being better for them. Don't flame me for this, it's just the truth: Jabber takes more setup, thought and time than MSN and the clients and network are not as appealing for teenagers. Deal with it.
Since then I haven't bothered again, it would just be a repeat performance. Therefore I really want to be able to access MSN from my computer, this is one of the no1 electronic ways (after texting) people of my age in England communicate. I could tell all my friends I wasn't going to talk to them online anymore because Microsoft was being evil blah blah blah, but most people don't really understand the interplays and market conditions in the IT industry and wouldn't really understand. Or, they would more likely take it as a personal affront - "he won't just install MSN to talk to me, I guess he doesn't like me" etc.
So, I use MSN because it's the lesser of two evils. If they started blocking me of course they'd have a legit business motive for that but I'd still be pissed off because I never wanted to use their services in the first place. I have to use it though OR not talk to any of my friends online. Once you start boycotting companies like that you end up with the Nestle situation where people run "boycotts" against their milk but still eat chocolate or breakfast cereals manufactured by them without even realising it.
So that's one reason why people are bitching about it. I think it's perfectly justified: if my friends choice of service didn't affect my choice of service (like with email) I'd have no problem. But it does.
For DK+DK2 if you have a crash on startup try running it like "wine c:\keeper\keeper.exe", ie use an absolute path. There's a bug in the game that causes it to crash if you run it from the directory it was installed to, ie without a path. Explorer never does this hence the fact that as long as you use the gui it works in Windows.
Are you sure it's wise to use something as out of date as Debian Stable? If you don't want the instability of something like Unstable, why not base it off Fedora or something with equally regular and predictable freezes?
I'm no expert, but it gives me some feeling of being better "sandboxed" so rogue applications don't escape from the emulated system.
Well, if you mean Wine, that's only a problem for apps that are specifically designed to detect that they are running under emulation on Linux and then start executing native Linux code - not a trivial feat! More to the point, how many apps are there that do this? Almost certainly the answer is none.
He's talking about the binary extension API which yes they break frequently and yes this causes tremendous pain to people distributing Python apps with binary extension modules.
This sort of thing is rife in Windows. They have special code to repair the stack for programs that define WndProc with the wrong calling convention - indeed, using the wrong calling convention is such a common mistake that all kinds of code has embedded assembly to repair it: even relatively modern stuff like the shell and DirectX!
That's not really accurate - as Joels article pointed out Apple have a much worse track record of backwards compat than Microsoft do. Apples Java team in particular need to be smacked about a bit - they're broken compatability with updates which they then pulled from the update service, leaving some users trapped in an incompatible limbo with no way for developers to get their system into the same state as their users.
Painful. Not to mention all the apps that stop working whenever major upgrades to OSX are released. I know most of them are eyecandy hacks, but even so, such things exist for Windows (eg WindowBlinds) and rather than break their apps Microsoft hired the guys who did it!
API's are a black box: you pass them values, they return some.
All you need to know is what to feed them and what to expect in return.
OK, no offence but it's pretty clear that you've not done a huge amount of programming, at least, not with APIs of any size.
No API of any complexity at all is a "black box" - they are often backed by millions of lines of code, and that code, just like application code, will contain bugs and odd behaviours. The documentation will be incomplete - very few people can spec out a complex API to the degree needed to truly understand it, even when you have documentation coming out of your ears like with MSDN.
Even assuming the API is perfection itself, it'll always be lacking SOME feature you want. Openness of an API is a very important thing indeed.
Slashdot Mirror
I'm glad you think it's straightforward. The months it took to develop the SHM wineserver were just because TransGaming like making things hard for themselves I guess. It had nothing to do with the fact that while Alice is like the Quake engine it actually is not Quake but rather an entirely different game. In the case of Alice, it was its mutex-swapping behaviour which caused the development of the SHM wineserver to speed up such pathological speed cases.
But it seems that the dream of great language interop has not been reached even with .NET - look at the work Nat+Trow are doing with Beagle/Dashboard. Rather than use the .NET CLR tools to reuse the Lucene search engine (written in Java), they forked it and rewrote it in C# - why?!
I see this even more. Interop is great in theory, but lacking in practice. See how they started out by using libxml/libxslt to implement the System.Xml APIs and then abandoned that and wrote their own in C#, partly because C interop was not good enough/high performance enough.
To be frank, I think Mono isn't going to unify anything. People will still code in C, C++, Python, C# and so on, and they will all be running in their "native" forms. So we just have yet another platform that needs to be bridged for useful work to get done (via some kind of COM-like technology).
Firefox is actively developed, which helps enormously. The IE team are just getting back together.
Still, Firefox could be better. For instance XBL bindings should not be allowed in user style sheets.
If anything Firefox is more hackable than IE, as if you can get write access to its directory then you can basically rewrite its UI logic as you see fit.
Sure it can hide itself, just ptrace an already running program and inject some code into a well known process that way.
Don't be fooled though - SELinux is great but it's purely damage control. It's only useful once your system has already been compromised.
Actually, running as non-root provides almost no protection against viruses as most things they want to do can be done as user (send email, modify webpages using CSS/XBL, hijack programs etc). Root is a good security system on a server, but the security challenges facing the desktop are entirely different.
Yes I know there are no viruses today. That's what wargaming is for. Be prepared. It's the only way.
So write them for Linux instead - integration into the OS there is the highest honour as it will be your work used by millions. No, you won't make money off it directly, but there was never much money in shareware anyway. You can make money indirectly - people can see your skill firsthand. I've already had work offers thanks to my volunteer open source project and due to my involvement with another (Wine), now have a job working on free software that I'm very happy with.
Well, he said that it was linked against GTK+ statically so by definition ldd would not show it.
KParts is little more than a glorified C++ classloader, it's definitely NOT an equivalent to OLE feature-wise. If you think it is, you need to learn more about OLE ....
Yes.
Visual Studio has working precompiled headers out of the box.
This is now true of GCC as well.
Visual Studio has a good incremental build system (and fix-and-debug support).
That's not related to the compiler, that's just a function of the IDE. I sometimes use flymake mode in emacs to achieve a similar effect. It's less cool than the VS equivalent but does work in a lot more situations.
GDB C++ support is a wreck; it has trouble demangling symbols, it chokes on template instantiations, and it gets line-number confused.
I don't know about that but I've never heard of such problems nor encountered them myself ...
GDB thread support is a wreck.
That's no longer true on a modern distro
Visual Studio generates better X86 code than GCC.
That's true. Flip side is that VS only generates X86 code, which isn't always what you want.
The Visual Studio UI canvas is better integrated with the compiler than Glade is with GCC.
Again you are confusing the compiler with the IDE. In fact, while the Glade/environment separation is sometimes annoying it's mostly useful. It means you can use whatever editor/coding environment you want unlike with Visual Studio where if you want to use the VS form designer you must use the VS editor, VS build system etc etc. Separate tools do not necessarily imply lack of integration even if in this case Glade is rather lacking.
* Disable XPInstall entirely. You can install XPIs by loading from the file manager, in place installation is convenient but dangerous. It's already been abused by scumware authors despite Firefoxes minimal market share.
* Compile Moz/FF with ProPolice or similar stack guard technologies, if it's possible.
* Implement opt-out URL blacklisting with the updated [signed] list being retrieved from DNS caches (or something similar to reduce load)
* Audit the code and perform wargaming (ie have organized hack events where people try and break Mozilla security), perhaps offer prizes for discovering holes in it.
I want us to start doing some of these things for Linux in the near future, but trialling these sort of techniques on Mozilla is a good plan,
How did you figure that one out? At least, according to eWeek this is some kind of buffer overflow or something, the image can force IE to run arbitrary code which then (surprise surprise) contacts Russian and US trojan servers.
Basically: create an XPCOM component in C++ (if JavaScript or Python are too slow for you) which performs the computation. Mark your XPCOM interface as scriptable, use the typelib compiler to expose it to javascript then pass in the browser DOM so it can be edited by your component. Then write an extension to catch "page loaded" and pass the DOM to the loaded XPCOM component. I think that should work.
They don't have to release their software. All they have to do is all agree to use an open, standardised protocol like Jabber/XMPP or something else, and then stick to it. They could even keep ads in their own clients, just prevent users logging into their accounts with 3rd party clients but still allow 3rd party clients to connect via other servers/accounts. This is what Hotmail does, for instance.
As it is, the IM companies are all too reliant upon network effects sucking more users in to compete effectively on their service quality instead of how many users they have.
As it happens, I do not know anybody who uses Y!IM so I do not care about this. The story would be very different if it was MSN Messenger. I use Linux, my job requires it in fact, and of course there is no official MSN client for Linux and probably never will be. I would LOVE for all my friends to use Jabber, but I tried many years ago to persuade said friends to use Jabber instead of MSN and to be frank MSN beat the snot out of Jabber through being better for them. Don't flame me for this, it's just the truth: Jabber takes more setup, thought and time than MSN and the clients and network are not as appealing for teenagers. Deal with it.
Since then I haven't bothered again, it would just be a repeat performance. Therefore I really want to be able to access MSN from my computer, this is one of the no1 electronic ways (after texting) people of my age in England communicate. I could tell all my friends I wasn't going to talk to them online anymore because Microsoft was being evil blah blah blah, but most people don't really understand the interplays and market conditions in the IT industry and wouldn't really understand. Or, they would more likely take it as a personal affront - "he won't just install MSN to talk to me, I guess he doesn't like me" etc.
So, I use MSN because it's the lesser of two evils. If they started blocking me of course they'd have a legit business motive for that but I'd still be pissed off because I never wanted to use their services in the first place. I have to use it though OR not talk to any of my friends online. Once you start boycotting companies like that you end up with the Nestle situation where people run "boycotts" against their milk but still eat chocolate or breakfast cereals manufactured by them without even realising it.
So that's one reason why people are bitching about it. I think it's perfectly justified: if my friends choice of service didn't affect my choice of service (like with email) I'd have no problem. But it does.
For DK+DK2 if you have a crash on startup try running it like "wine c:\keeper\keeper.exe", ie use an absolute path. There's a bug in the game that causes it to crash if you run it from the directory it was installed to, ie without a path. Explorer never does this hence the fact that as long as you use the gui it works in Windows.
Are you sure it's wise to use something as out of date as Debian Stable? If you don't want the instability of something like Unstable, why not base it off Fedora or something with equally regular and predictable freezes?
Well, if you're going to be as scientific as that here's the ldd list for kmail:
/opt/kde3.2.1/lib/libkmailprivate.so.0 (0x40017000) /opt/kde3.2.1/lib/libkhtml.so.4 (0x403b7000) /usr/lib/libjpeg.so.62 (0x406aa000) /opt/kde3.2.1/lib/libkjs.so.1 (0x406c8000) /usr/lib/libpcreposix.so.0 (0x40729000) /lib/libpcre.so.0 (0x4072c000) /opt/kde3.2.1/lib/libkdeprint.so.4 (0x4073d000) /opt/kde3.2.1/lib/libkparts.so.2 (0x407fa000) /opt/kde3.2.1/lib/libkutils.so.1 (0x4083d000) /opt/kde3.2.1/lib/libkwalletclient.so.1 (0x40891000) /opt/kde3.2.1/lib/libkdenetwork.so.2 (0x408a0000) /opt/kde3.2.1/lib/libkspell.so.4 (0x40970000) /opt/kde3.2.1/lib/libkdepim.so.1 (0x40973000) /opt/kde3.2.1/lib/libmimelib.so.1 (0x409c9000) /opt/kde3.2.1/lib/libktnef.so.1 (0x409fd000) /opt/kde3.2.1/lib/libksieve.so.0 (0x40a13000) /opt/kde3.2.1/lib/libkcal.so.2 (0x40a21000) /opt/kde3.2.1/lib/libkabc.so.1 (0x40af7000) /opt/kde3.2.1/lib/libvcard.so.0 (0x40b98000) /opt/kde3.2.1/lib/libkresources.so.1 (0x40bba000) /opt/kde3.2.1/lib/libkio.so.4 (0x40bdf000) /opt/kde3.2.1/lib/libkdeui.so.4 (0x40ee0000) /opt/kde3.2.1/lib/libkdesu.so.4 (0x41159000) /opt/kde3.2.1/lib/libkdecore.so.4 (0x41173000) /opt/kde3.2.1/lib/libDCOP.so.4 (0x41353000) /lib/libresolv.so.2 (0x41383000) /opt/kde3.2.1/lib/libart_lgpl_2.so.2 (0x41395000) /opt/kde3.2.1/lib/libkdefx.so.4 (0x413a9000) /opt/kde3.2.1/lib/libqt-mt.so.3 (0x413d2000) /usr/lib/nvidia/tls/libGL.so.1 (0x41a0f000) /usr/X11R6/lib/libXmu.so.6 (0x41a6d000) /usr/X11R6/lib/libXrandr.so.2 (0x41a83000) /usr/X11R6/lib/libXcursor.so.1 (0x41a87000) /usr/X11R6/lib/libXft.so.2 (0x41a90000) /usr/lib/libfreetype.so.6 (0x41aa2000) /usr/lib/libfontconfig.so.1 (0x41af2000) /lib/libdl.so.2 (0x41b1a000) /usr/lib/libpng12.so.0 (0x41b1d000) /usr/X11R6/lib/libXext.so.6 (0x41b40000) /usr/X11R6/lib/libX11.so.6 (0x41b4e000) /usr/X11R6/lib/libSM.so.6 (0x41c2c000) /usr/X11R6/lib/libICE.so.6 (0x41c34000) /lib/tls/libpthread.so.0 (0x41c4c000) /usr/X11R6/lib/libXrender.so.1 (0x41c5c000) /lib/libutil.so.1 (0x41c64000) /usr/lib/libz.so.1 (0x41c67000) /usr/lib/libfam.so.0 (0x41c78000) /usr/lib/libstdc+
libkmailprivate.so.0 =>
libkhtml.so.4 =>
libjpeg.so.62 =>
libkjs.so.1 =>
libpcreposix.so.0 =>
libpcre.so.0 =>
libkdeprint.so.4 =>
libkparts.so.2 =>
libkutils.so.1 =>
libkwalletclient.so.1 =>
libkdenetwork.so.2 =>
libkspell.so.4 =>
libkdepim.so.1 =>
libmimelib.so.1 =>
libktnef.so.1 =>
libksieve.so.0 =>
libkcal.so.2 =>
libkabc.so.1 =>
libvcard.so.0 =>
libkresources.so.1 =>
libkio.so.4 =>
libkdeui.so.4 =>
libkdesu.so.4 =>
libkdecore.so.4 =>
libDCOP.so.4 =>
libresolv.so.2 =>
libart_lgpl_2.so.2 =>
libkdefx.so.4 =>
libqt-mt.so.3 =>
libGL.so.1 =>
libXmu.so.6 =>
libXrandr.so.2 =>
libXcursor.so.1 =>
libXft.so.2 =>
libfreetype.so.6 =>
libfontconfig.so.1 =>
libdl.so.2 =>
libpng12.so.0 =>
libXext.so.6 =>
libX11.so.6 =>
libSM.so.6 =>
libICE.so.6 =>
libpthread.so.0 =>
libXrender.so.1 =>
libutil.so.1 =>
libz.so.1 =>
libfam.so.0 =>
libstdc++.so.5 =>
Actually there are lots of useful undocumented APIs. Check out the unnamed shell32 exports or NTDLL
Well, if you mean Wine, that's only a problem for apps that are specifically designed to detect that they are running under emulation on Linux and then start executing native Linux code - not a trivial feat! More to the point, how many apps are there that do this? Almost certainly the answer is none.
He's talking about the binary extension API which yes they break frequently and yes this causes tremendous pain to people distributing Python apps with binary extension modules.
This sort of thing is rife in Windows. They have special code to repair the stack for programs that define WndProc with the wrong calling convention - indeed, using the wrong calling convention is such a common mistake that all kinds of code has embedded assembly to repair it: even relatively modern stuff like the shell and DirectX!
Painful. Not to mention all the apps that stop working whenever major upgrades to OSX are released. I know most of them are eyecandy hacks, but even so, such things exist for Windows (eg WindowBlinds) and rather than break their apps Microsoft hired the guys who did it!
OK, no offence but it's pretty clear that you've not done a huge amount of programming, at least, not with APIs of any size.
No API of any complexity at all is a "black box" - they are often backed by millions of lines of code, and that code, just like application code, will contain bugs and odd behaviours. The documentation will be incomplete - very few people can spec out a complex API to the degree needed to truly understand it, even when you have documentation coming out of your ears like with MSDN.
Even assuming the API is perfection itself, it'll always be lacking SOME feature you want. Openness of an API is a very important thing indeed.