The only exception to that rule is if the API is broken to the point of unusable AND there's no workaround
That would pretty accurately describe the NT4 security APIs, at least. Even Microsoft avoids them and just sticks with the NT3.5 APIs.
Hmm, I guess you're right. That does count as a workaround.
Which is a shame, because using the NT3.5 APIs means serializing all the complex structures yourself, subject to all kinds of stupid alignment requirements.
One of the most blatant is the NT4 security APIs; at least up through W2K and current patches (I've not investigated XP yet), they're severely broken.
I mean, broken to the point that you have to fall back to the older NT 3.5 APIs to do nontrivial things. One of the worst is stripping portions of ACLs when you try to write them. For simple objects it's not (usually) a problem, but for anything non-trivial.
Hit google groups and browse some of the results for "SetNamedSecurityInfo" or "SetSecurityInfo". Results like this one, which are characteristic of the problems I've run into.
I didn't believe it could be that bad, until I tried writing code against these APIs myself.
Most of the Windows subsystems aren't quite that bad, but it's not _that_ far from the pale even so.
I assume this means that the developers just aren't looking at them very much. The alternative would be that they don't just give a crap...
Having recently done a GNOME build from scratch on HP-UX, I had to work out the dependencies (I just used a makefile rather than figuring out the optimum order by hand).
As far the core GNOME libraries go, though, here's an excerpt from the dependencies section of my top-level makefile. If you start from the bottom of this list and work your way up, installing the dependencies before you install each library/package, you should be OK.
(you may already have some, like xrender, if you have recent XFree86)
Well, Geoff forwarded me a copy of the DEC message, and I eat my words. I sure would have minded it! Nobody should be allowed to send a message with a header that long, no matter what it is about.
He seems to have had trouble grasping the nature of SPAM before he saw it personally.
How soon before we can jump from large heights? Say jumping from a 2 story building. Where the legs act as a shock absorber. Or what about jumping over large distances? Something similar to the Hulk.
The problem is that with normal-length legs, you only have so much space to accelerate/decelerate in.
Typically you'll have maybe three feet of play between standing and a full squat. That means that when jumping, you'll have to accelerate to your maximum velocity in that three feet, and when you land, you'll need to slow down by the same amount.
For even mildly superhuman distances, you'd end up pulling some serious Gs -- and if you don't slow down fast enough when landing, you run out of leg and get to do all that deceleration all at once when you impact the ground.
When exerting superhuman forces (as in attempting to jump very high, or, say, lifting a tank), there's also the problem in that you'll be exerting a large amount of force over a very small area (i.e. that of your feet) of the surface you're standing on. Past a certain point, you're more likely to create (and fill) a you-shaped indentation in the ground than you are to do anything particularly impressive.
Well, one thing to realize is that treaties do in many cases supercede the laws of signatory states (in the US, for example, treaties supercede even the constitution). There's also a lot of peer pressure applied between member states when some have signed a treaty and some have not (in part because the signatories naturally feel put at a disadvantage).
This isn't specific to the UN, of course; in general, multinational bodies tend to become tools for a few of the most powerful states (i.e. whoever can create the most economic/political pain for the others) to shape the policy and law of all the member states.
I guess if you wanted to pick on the UN Universal Declaration of Human Rights specifically you could always cite things like Article 29, pragraph 3:
These rights and freedoms may in no case be exercised contrary to the purposes and principles of the United Nations.
The reason they are still extensions and not moved into the core is that that would essentially mean X11R7, and a loss of upwards-compatability from a server persepective.
So, doing that would actually make the compatability problem worse, not better, without gaining much else.
Regardless, I don't think Y is a waste of effort, anyway, succeed or fail. If you look at my posting history a few years back, I was a major supporter of Fresco (at the time, called Berlin).
I don't think Fresco will ever take off at this point (CORBA being just a weeee bit too nasty, among other things), but a lot of people benefited just from the work that was spent on it. Actually some significant Berlin/Fresco alumni are now taking their experience to FreeDesktop.org, too.
Y has fewer obstacles to an active life, I think. There's no shame in reinventing the wheel (look at the array of specialized wheel designs out there!), but just be aware that you may end up repeating the design you intend to replace.
The design goals of X11 were also a "...protocol that people can support (and hopefully, extend) to add things that [its designers] didn't think of (or that aren't practical) yet.". Realistically, the only way to achieve that is through something like X11's extension mechanism. If Y takes a similar approach, it'll end up facing the same evolutionary pressures as X11.
We have all these extensions that make our life easier, but make coding harder, since they're exactly that - extensions to a protocol designed by people who had no idea what they were doing (which is why they created extensions). If these extensions are as usefulas they are, why not make them the new standard?
I wouldn't exactly call Keith Packard someone who has no idea what he's doing when it comes to X Windows, and folks like Jim Gettys seem to trust his judgement...
That said, perhaps I'm missing how using XRender makes things harder than using the core drawing operations from a programmer's perspective. As far as I can tell provides a consistent API that works on any X server (the worst that can happen is that it's not performed as optimally as they could be), but my experience with it is still limited.
Which won't work on other X implementations, or older versions of XFree, or versions where that module isn't loaded (e.g. where an old configuration is used
I used to think that too, but recently I had to build Gnome 2 on HP-UX (with HP-UX's proprietary X server, not the XFree86 port).
It uses XRender on the servers that support it, and falls back to client-side rendering on those that don't. You do need the XRender client-side library, but thanks to fd.o, that's no longer tied to XFree86 -- they offer a standalone autoconfed version.
Hence XRender and the introduction of a new visual type with an alpha channel done by FreeDesktop.org, both done in a non-crufty way, yet within the confines of the existing X protocol.
that's like saying the beatles can sue every musician who ever listened to them for copyright infringement
I personally think it's a bad analogy, but even that isn't as far-fetched as you might think.
George Harrison (of Beatles fame) was succesfully sued for _subconsciously_ ripping off the song "He's So Fine" (in "My Sweet Lord"). See here for more details.
So, no, I don't think worrying about IP contamination from looking at Windows source code is paranoid at all.
I for one would love to peek around in this, more out of curiosity than any desire to actually do something useful with it.
I hope you weren't planning on ever contributing to any Open Source projects after doing that. If it's later demonstrated that you had access to the W2K source and contributed vaguely similar code (even by accident) to a project, it could have severe repercussions for that project.
I doubt Microsoft would leak it deliberately, but this does open the door to a whole SCO-esque can of worms from now on.
Slashdot Mirror
I suppose there is some truth to the "what doesn't kill you makes you stronger" theory.
That would pretty accurately describe the NT4 security APIs, at least. Even Microsoft avoids them and just sticks with the NT3.5 APIs.
Hmm, I guess you're right. That does count as a workaround.
Which is a shame, because using the NT3.5 APIs means serializing all the complex structures yourself, subject to all kinds of stupid alignment requirements.
Well, it kind of shows.
One of the most blatant is the NT4 security APIs; at least up through W2K and current patches (I've not investigated XP yet), they're severely broken.
I mean, broken to the point that you have to fall back to the older NT 3.5 APIs to do nontrivial things. One of the worst is stripping portions of ACLs when you try to write them. For simple objects it's not (usually) a problem, but for anything non-trivial.
Hit google groups and browse some of the results for "SetNamedSecurityInfo" or "SetSecurityInfo". Results like this one, which are characteristic of the problems I've run into.
I didn't believe it could be that bad, until I tried writing code against these APIs myself.
Most of the Windows subsystems aren't quite that bad, but it's not _that_ far from the pale even so.
I assume this means that the developers just aren't looking at them very much. The alternative would be that they don't just give a crap...
It cuts the kernel stack down to a single 4k page. There are performance advantages to doing this.
The main caveat is that drivers (and other kernel code, really) have to be very careful about their stack usage, or they run out of stack.
Consequently, badly written binary drivers with fat glue layers are right out...
...which was putatively located in Mesopotamia (i.e. Iraq).
There we go. Full circle. ^_-
Having recently done a GNOME build from scratch on HP-UX, I had to work out the dependencies (I just used a makefile rather than figuring out the optimum order by hand).
As far the core GNOME libraries go, though, here's an excerpt from the dependencies section of my top-level makefile. If you start from the bottom of this list and work your way up, installing the dependencies before you install each library/package, you should be OK.
(you may already have some, like xrender, if you have recent XFree86)
GConf: popt glib ORBit2 libxml2 gtk+
libgnomeui: gtk+ libxml2 libgnome libgnomecanvas libbonoboui libbonobo
libgnome: glib gnome-vfs libbonobo GConf
gnome-vfs: glib libxml2 libbonobo ORBit2 GConf gnome-mime-data
libbonoboui: gtk+ libbonobo libgnomecanvas libxml2 GConf
libgnomecanvas: gtk+ libart_lgpl pango
libbonobo: glib libxml2 ORBit2
libgsf: glib libxml2
libglade: libxml2 gtk+ atk
gtk+: glib atk pango
pango: glib freetype fontconfig xft
ORBit2: popt glib libIDL
xft: fontconfig freetype xrender
fonts: fontconfig
fontconfig: freetype expat
atk: glib
xrender: render
render: pkgconfig
glib: pkgconfig
If I understand correctly, you can still do that. The selection moves to the filename you're typing as you type.
ER, sorry. That should be bloodshed.net ...
Are you familiar with DevC++? It's at least a tolerable free IDE w/ mingw-based compiler that is usable for Windows development.
He seems to have had trouble grasping the nature of SPAM before he saw it personally.
The difference is that the grenade trick would only work once.
Because infantry often has to go where wheels can't.
Otherwise there wouldn't be much point in having infantry.
(also, it's cheaper)
The problem is that with normal-length legs, you only have so much space to accelerate/decelerate in.
Typically you'll have maybe three feet of play between standing and a full squat. That means that when jumping, you'll have to accelerate to your maximum velocity in that three feet, and when you land, you'll need to slow down by the same amount.
For even mildly superhuman distances, you'd end up pulling some serious Gs -- and if you don't slow down fast enough when landing, you run out of leg and get to do all that deceleration all at once when you impact the ground.
When exerting superhuman forces (as in attempting to jump very high, or, say, lifting a tank), there's also the problem in that you'll be exerting a large amount of force over a very small area (i.e. that of your feet) of the surface you're standing on. Past a certain point, you're more likely to create (and fill) a you-shaped indentation in the ground than you are to do anything particularly impressive.
Food, water, shelter, and batteries.
Cable lines are shielded (COAX); power lines aren't (and can't be, really, at those power levels).
you are apparently correct
Well, one thing to realize is that treaties do in many cases supercede the laws of signatory states (in the US, for example, treaties supercede even the constitution). There's also a lot of peer pressure applied between member states when some have signed a treaty and some have not (in part because the signatories naturally feel put at a disadvantage).
This isn't specific to the UN, of course; in general, multinational bodies tend to become tools for a few of the most powerful states (i.e. whoever can create the most economic/political pain for the others) to shape the policy and law of all the member states.
I guess if you wanted to pick on the UN Universal Declaration of Human Rights specifically you could always cite things like Article 29, pragraph 3:
Isn't that a prime piece of weasel wording?
The reason they are still extensions and not moved into the core is that that would essentially mean X11R7, and a loss of upwards-compatability from a server persepective.
So, doing that would actually make the compatability problem worse, not better, without gaining much else.
Regardless, I don't think Y is a waste of effort, anyway, succeed or fail. If you look at my posting history a few years back, I was a major supporter of Fresco (at the time, called Berlin).
I don't think Fresco will ever take off at this point (CORBA being just a weeee bit too nasty, among other things), but a lot of people benefited just from the work that was spent on it. Actually some significant Berlin/Fresco alumni are now taking their experience to FreeDesktop.org, too.
Y has fewer obstacles to an active life, I think. There's no shame in reinventing the wheel (look at the array of specialized wheel designs out there!), but just be aware that you may end up repeating the design you intend to replace.
The design goals of X11 were also a "...protocol that people can support (and hopefully, extend) to add things that [its designers] didn't think of (or that aren't practical) yet.". Realistically, the only way to achieve that is through something like X11's extension mechanism. If Y takes a similar approach, it'll end up facing the same evolutionary pressures as X11.
I wouldn't exactly call Keith Packard someone who has no idea what he's doing when it comes to X Windows, and folks like Jim Gettys seem to trust his judgement...
That said, perhaps I'm missing how using XRender makes things harder than using the core drawing operations from a programmer's perspective. As far as I can tell provides a consistent API that works on any X server (the worst that can happen is that it's not performed as optimally as they could be), but my experience with it is still limited.
Which won't work on other X implementations, or older versions of XFree, or versions where that module isn't loaded (e.g. where an old configuration is used
I used to think that too, but recently I had to build Gnome 2 on HP-UX (with HP-UX's proprietary X server, not the XFree86 port).
It uses XRender on the servers that support it, and falls back to client-side rendering on those that don't. You do need the XRender client-side library, but thanks to fd.o, that's no longer tied to XFree86 -- they offer a standalone autoconfed version.
It works great.
Hence XRender and the introduction of a new visual type with an alpha channel done by FreeDesktop.org, both done in a non-crufty way, yet within the confines of the existing X protocol.
I don't know about NoteEdit, but RoseGarden has been doing at least that much for a very long time now. You may want to give it another look.
I personally think it's a bad analogy, but even that isn't as far-fetched as you might think.
George Harrison (of Beatles fame) was succesfully sued for _subconsciously_ ripping off the song "He's So Fine" (in "My Sweet Lord"). See here for more details.
So, no, I don't think worrying about IP contamination from looking at Windows source code is paranoid at all.
More like a dagger in OSS's heart, due to IP contamination.
I hope you weren't planning on ever contributing to any Open Source projects after doing that. If it's later demonstrated that you had access to the W2K source and contributed vaguely similar code (even by accident) to a project, it could have severe repercussions for that project.
I doubt Microsoft would leak it deliberately, but this does open the door to a whole SCO-esque can of worms from now on.