The only part of this that isn't obvious is why to use IPv6. Actually, that's obvious, too--it's fun to play with new things.
There's a little more to it than that. IPv6 has a much bigger address space - which won't affect you directly - and also has much-enhanced security features and the ability to set up links with predictable real-time performance (IOW it's ideal for Quake). --
A central configuration system would be neat, but on the other hand you would break compatibility with a lot of existing Unix applications which expect/etc,/proc, and so forth. I guess you could set up this database in a different directory and only new apps would know about it. Better make it flat text, though - I don't think a binary registry will fly very far.
Proc is well on its way to being a registry, except one that doesn't suck. All it needs is persistant storage. --
And it doesn't scare me at all that Linux apparantly has this goal, because it hasn't nor is it able to replace NT... The problem with you and your fellow advocates is: you don't understand the people you're talking to.
With all due respect, it seems to be you who doesn't understand. Check this out.
This attitude also says to me I never HOPE to be called a Linux User if the loud mouth zealots keep their attitude.
Well then you can make it your mission to do your part to correct this bad behavior and I'll do my part to clue you in on which way the wind is blowing. --
If Linux would be equipped with a client for win32 (like the client for netware) it would be ok.
No, you just don't get it. Linux is already a perfectly good SMB client - but has greater ambitions - Linux is a great SMB server too, and is also reportedly a darn good NT-replacement domain server (though I haven't tried it myself). If as a MS camp follower that doesn't scare you, then you just don't understand the situation.
Course if you're a user you should be nothing but pleased, because who wouldn't mind having a domain server that costs nothing and doesn't needed to be rebooted once/fortnight?
You apparantly are not well informed and believe that if a person just knows something about win32 he's a microsoft employee;) hahhaha:) that really made my day.
Oh yes, how clever of you.:) I should have said "Microsoft Toady".
The samba issue is an NT domain issue: a user has to be logged in on a Domain so it gets a Security token that it can use to access other resources within the domain. If you use a Sambaserver and you don't have an NT domain server, you can't use the domain security model (I think that's clear), so that's why there has to be a domain server to use samba.
Yes and personally I'd prefer that that domain server be running Linux or BSD, which is perfectly possible, and in fact widely done. This works well but there are a few inoperability issues caused solely by Microsoft's hiding of API information, and intentional creation of complex buggy interfaces just to make it harder to create compatible products. Which of course hurts the consumer in a number of ways including make the software more bug-prone and limiting their choice to a single, abusive supplier and an overpriced product.
I dunno, I think if I had to rely on someone's advice I'd go with huusker before I'd listen to you;-) And I'll put my money on the Samba team's ability to continue cracking Microsoft's secret APIs faster than Microsoft can create new ones. Anyway, by now it should be obvious that the only people lame enough to keep reading this old thread are Microsoft employees and me:-)
wishing you good luck with clib
Errr... that's glib. You know, I used to feel like I'd been slimed after every online encounter with a Microsoft employee, but now I feel more like the way I feel after talking to a Moonie - there's a real chance that I may be able to help deprogram them, especially If they've already take the first step by hanging on Slash without being told to do it. There's no preacher like the converted.
BTW, the "g" in "glib" stands for "Gimp", which stands for "Gnu Image Manipulation Program" and Gnu in turn stands for "Gnu's not Unix". Isn't that cool? And plus, "glib" also means exactly tha: it really is a slick library. --
Microsoft isn't out there to help competitors reverse engineer their work.
While I have great sympathy for the need of rich corporations (and rich sons of rich lawyers) to become yet richer, I think the general public's need to be protected from substandard products (gas tanks that explode anyone?) outweighs Microsoft's need to keep its APIs secret, which serves no other purpose than derailing attempts to make products that work well with Microsoft operating system but aren't sold by Microsoft. --
Do you have a more detailed description on how you want this to work?
A good place to start is Newman & Sproul, Principals of Interactive Graphics - check out the section on scanline rendering. The Quake articles written by Michael Abrash are an excellent source, and they go into a lot of useful detail (some but not all of which is only relevant to 3D) To answer somebody else's question, no I'm not an Amiga user but this is just the obvious way to do it. And the corollary is, check out exactly how it was done on the Amiga (I haven't, I'm curious). If the shoe fits, wear it.
Does it increase the amount of memory needed by the server?
No. One of the nice things about scanline renderers is how little memory they use. Of course you can add buffering as an accelerator depending on how much memory happens to be available.
Does it increase the amount of network traffic needed?
It would have no impact on that: exactly the same render commands are sent by the applications. The only extra traffic would be for animation programs synchronizing with the refresh, and that would be miniscule.
How would it cope with for example a Netscape window that was 500 pixels by 100 thousand, which you wanted to scroll smoothly through?
The same way it does now: send a command to scroll the part that doesn't change, clear and redraw the part that does, run the part that goes off the screen into a memory buffer as memory permits. The thing is, all of the transfers to the screen actions would be delayed until the Netscape program says "go ahead and do it". Then all the renders are done, optionally deffering rendering for regions that are not visible, but retaining the commands in case they become visible, (so you don't have to ask the app to regen the region). When it's time to update the screen, you do one of two things depending on whether you have hardware accel or not. With hardware the renderer does a scroll blit and a put blit for the browser window, or multiple scrolls and blits if the window is broken up, but only for the regions actually visible. Without hardware you work your way down the region a line at a time doing the minimal thing to each line, which may be copying it from another part of the screen (slow) copying it from previously buffered data, or putting it from the new render region.
It's also nice to be able to work in an unbuffered mode where all drawing is direct to the screen and the renderer clips each primitive as it's drawn. Needless to say this is much slower and you get flickering, and implementing such clipping primitives efficiently and accurately is hard. But it's very helpful so you can see exactly what your program was doing when it crashed, or exactly why you're getting a messy blob when you should be getting a nice web page. Running the render in slo-mo gives you a graphics debugger.
I've never actually done all this (except in 3D rendering code) so I probably missed a few important points, but I think this is the general idea.
To put all this in perspective, run xpenguins or xroach and notice how much the rendering sucks, and think about what you could do about that. --
We now come to the fact why people whine about this: they think win32 function equivalents are slow, crippled and crap, and they demand access to the layers below win32 just because they THINK MS' major applications do use these layers INSTEAD of the win32 equivalents.
Well, I don't see how you've addressed Huusker's original point that, among other things, certain key functionality couldn't be implemented in Samba because it's undocumented. How is the Win32 API going to help there? Stop! Don't answer, I'll answer for you: it isn't. So please take your Win32 API and stuff it where the... oh, I mean Win32 just isn't the whole story.
Now, I'd like to say one thing: as soon as I saw the word "whine" in your post your credibility dropped to exactly zero. Why? Because that's a stock Microsoftism, right up there with "innovation". So, all I have to say is "next, please". I asked for someone to clue me in and you're just trying to snow me. --
I made a quick scan through your paper and it all looks right on the money. We need alpha; we need rotation; we needed zoomable/scalable/rotatable everthing.
I'd like to add a suggestion. 2D rendering is best done much like 3D software rendering: with something like a scanline renderer that makes one pass from top to bottom to render each frame, rendering exactly what needs to be rendered and no more. Instead of depth you have window priorities. Unlike a 3D animation renderer, you optimize for the fact that most of the screen doesn't change at all (so, to respond to another poster's remark - OpenGL isn't the way to go for 2D rendering - it carries too much overhead with it.)
Applications can know or not know about this frame-oriented rendering. If they know about it then can do really smooth animation by synching their erase/redraw cycle with the rendering cycle.
Advantages to be gained are: Software cursors that don't flicker; animation that doesn't flicker; video windows that don't exhibit strange behavior when you drag other windows across them; Scrolling windows that don't have little flickery blank spots at the top/bottom. And you get way, way more possibilities for optimization.
And don't forget this principal: when it's all done it should be smaller and tighter than X is now, even while doing 5 times as much. Because we had time to think about it and factor it correctly. --
Excuse me for pointing out the blatantly obvious in your post, but none of the APIs you mentioned are used by the Apps team and none of them would require disclosure in a OS/Apps chinese wall.
Remember that applications are written to Win32 and not to the raw NT API hence NTCreateProcessToken(), Subsystem APIs and NTLM RPCs are not part of this.
Also, I've implemented authentication using NTLM over a socket quite happily using the published APIs. Your claim that Netscape cannot do this either implies that the guys at Netscape are fools or they have an alternate agenda. Look at the sample program in MSDN!!
I hate to say it but your post was ill informed, inaccurate and bordering on an outright lie.
John Wiltshire
Now, this debate interests me. Who is right, "John Wiltshire" or Huusker? Someone please hit me with a clue stick. --
Microsoft has done a heck of a lot to make people aware[...]"
"How many APIs does Sun document for StarOffice?"
First, does that "heck of a lot" sound like Steve Balmer or what???? *cough!*
Second, I belive that Sun has released the Staroffice code (though not with an "Open Source" compliant license). How better documented do you need?
Wouldn't it be absolutely the coolest thing if it really was Steve Ballmer? (And I was actually Linus, hehe.)
But who could seriously believe that hands-on control freaks like Bill and Steve could actually resist the temptation forever to go hang on Slash and post pro-Microsoft bafflegab. Not me. I bet each of them has done it at least once. --
NTLM RPC API Essential for doing DC operations to manage domain accounts. With this Samba could eliminate the need for NT Server. Still undocumented.
I'm pretty late posting this and it's nested pretty deeply so I don't really expect anyone to read this much less moderate it but here it is anyway...
This is the perfect time to sue Microsoft to get the needed api information. Think about it. Little open-source developer (with the help of the EFF) goes after big bad 800 pound Microsoft to get a little itty bitty piece of information that would benefit all mankind. With the opensource world, the DOJ, and needless to say, the supreme court watching carefully. Should they try to put up any meaningful kind of a fight the negative publicity and probable negative legal fallout for Microsoft would be astounding.
Just sue for one little piece of information, get it, and the floodgates will open. Microsoft would never dare hold anything back after that. --
At $0.50 / download it will require 12,000,000 downloads to return 100% profit, not a bad business at all. Otherwise you are paying half what you'd pay to go to a movie for scarcely more rights to it and considerably worse quality.
For these numbers to work an efficient secure means of payment is needed but there's another bloated monopoly getting in the way of the consumer's quality of life.
How the hell are you gonna get 12 MILLION people to buy the movie?
Really, dear coward, that won't be a problem if it costs $0.50 to download it now. Don't get me wrong, I watch every John Cleese movie and I'll watch this one too, and pay for it. The thing is, it's easy to see the higher price as revenue maximizing, but that's exactly wrong. The way to sell a whole lot of burgers is to sell them for $2, not $20.
This may be possible in some years, but not now!
It's possible now if (1) you have a high bandwidth/low cost connection (many already do) and (2) a payment method is available that required essentially no effort on the part of the consumer, no harder than reaching into one's wallet, and (3) that payment method costs a fraction of a cent per transaction. I repeat: this is possible now, it's just that certain interests are standing in the way of having it actually happen. But someone with the drawing power of John Cleese can make it happen now if it matters to them to be seen as a visionary and not just another mouth feeding at the internet trough.
Note that if the price is too high for downloaded movies, and $5 is too high, we'll just have a nasty repeat of the RIAA fiasco where people are being turned into criminals because they refuse to continue to pay monopoly-inflated prices for artistic content that costs almost nothing to distribute, returning only a tiny fraction of the take to artists.
If you had made the movie you wouldn't be thinking this way. hypocrite.
If you had a spine you wouldn't be posting as an anonymous coward;-) --
At $0.50 / download it will require 12,000,000 downloads to return 100% profit, not a bad business at all. Otherwise you are paying half what you'd pay to go to a movie for scarcely more rights to it and considerably worse quality.
For these numbers to work an efficient secure means of payment is needed but that's another bloated monopoly getting in the way of the consumer's quality of like. --
...which is another reason it is not in the 2.3 version
I thought about it some more, and I realized that the principal that must apply, classically, "no news is good news". You are right to remove these messages. They shouldn't appear during package installation either. And there should be no code in the kernel module devoted to providing an option. That just takes up memory.
All the same, reading the credits gives me a warm and fuzzy. I just don't want it mixed in any way with the machinery of the OS. One excellent place to give credit/blow one's own horn in the package info of an RPM, as long as it's not too obtrusive and doesn't get in the way of the functional information. Another good place is in the usual CREDITS file that's often included in a package distribution. Do we need any more advertising that this? I really don't think so. As you said (more or less) being able to take credit on *one* web site that you own is worth many 1,000,000's of little boot nags. --
Actually I'm torn on whether I like them or not. These particular messages are certainly unobtrusive, modest, almost self-effacing. But still, it has nothing to do with how the computer boots. But still but still, I wouldn't mind having a generic place to put splash-type info, both for text mode and graphics, and some times I'd want to see it just out of interest. Especially the first time I boot a new distro.
To make sure this splash stuff stays informative and doesn't get irritating we need a generic way to turn it all off, and that method has to act early in the boot sequence. That means it has to be some kind of kernel flag, and everybody who wants to put in non-functional information (e.g. credits) has to use it. This would require a fairly broad concensus... --
Re:Take a look at job listing then...
on
Motif's Not Dead
·
· Score: 2
Now try to fing a job e.g. in the finance area with your wonderful Qt of GTK+ experience.
If getting a good job is your only motivation I suggest you bill yourself as a Java programmer - you'll earn more and probably get more projects completed than as an X hacker.
If you insist on building enterprise apps in C then use a Unix port of GTK, or pay for the QT licence - you can afford it. Motif is certainly a PITA to program but certainly is certainly the more powerful toolkit of the three. One thing that I can't stand with GTK+ is that preferences are host centric and not display centric... That's plain stupid, I can access the same app from many displays and certainly want preferences specific to the display, what if one is small and B&W and the other large and TrueColor, I certainly don't want the same font size and icons on both...
Thanks for pointing that out. I never noticed it in practice but I can see why you'd want that. I can think of more variations: sometimes I want my prefs to be specific to something very application-dependent, like a URL (just hate those sites that put teensy fonts on their web pages). I wonder how that could be handled elegantly. I'm sure we'll find a way.
GTK+ completely lost the network part of X... If I want a non network centric window system I can simply use Windows...
Err... no. GTK works perfectly well remotely - I was using it that way two nights ago, with the client running on Win NT no less. It gets this for free by running on top of X. --
There's been a lot of speculation about whether being broken up would make the sum of Microsoft's parts more or less valuable than the whole. Personally I think: Not.
Microsoft's market machine so far has acted like a nutcracker - squeezing customers and competitors alike between it's two jaws: control of application api's through the os on the one hand and control of competitive os's through the apps on the other. Breaking Microsoft into two parts will be much like removing the nutcracker's fulcrum. You may still be able to poke people with iether half, but can no longer break their nuts^H^H^H^H^H^H^H^H^H^crack nuts with it.
Without their made-in-heaven monopoly machine to fuel their unbelievable profitability there's only one direction for their earnings to go: down.
Microsoft's market cap is based on expectation of unending growth at a rate serveral times that of the computer industry as a whole. To date that fairytale has come true, year after year for more than 20 years. No longer. First, their earnings aren't going to grow any more, their going to shrink. Second, Ballmer is right - the rats^H^H^H^H^Hbrains are getting out. So are the execs. For the simple reason that Microsoft's options aren't worth a whole lot any more.
On that subject, absolutely the worst thing that could happen to Microsoft is a long slow decline in their stock price. This would be much more harmful that, for example, a sudden drop by a factor of 10. The reason? The long slow decline means that Microsoft options will never be worth a cent. Whereas if their stock would just fall into the basement and get it over with they could possibly once again use options as a useful tool.
There are other factors that will stress Microsoft's share price. Not the least of which is the availabilty of at least one superior alternative that costs nothing (or something, it's your choice). There is only one possible result. Microsoft will have to do major surgery on it's OEM prices and that means "goodbye 95% gross profit margin". In turn meaning more decline in the stock price.
And don't forget the upcoming class action suits, and the still-to-be-filed damage suits from competitors that suffered from their illegal practices.
All these troubles would be multiplied if any evidence of financial misrepresentation turns up.
OK, enough, enough. Time for my prediction. I predict that Microsoft's market cap will fall to less than that of General Motor's, which is somewhere in the $50 billion range. That means a further factor of 5 fall from where they are now. I predict that it will take a year to fall that low as shareholders really begin the understand the implications of losing at trial and being beaten by a free OS at the same time.
In the long run I don't see a lot of value in the Baby Bill's. I see the office monopoly eroding quickly, and I don't see the underlying problems of the software being fixed. I don't see Microsoft's good name ever being restored, nor Gate's. In short, I see Microsoft's total value falling to less than, for example, CA's, in other words, it's going to be decimated.
Well, Bill, it's going to be tough for you to swallow but sincerely believe you went out of your way to earn this. --
I'll go out on a limb and say that Gates will choose to abandon the OS company (calling it Windows), and go with the apps company, which would retain the Microsoft name.
I'll go even further out on a limb and predict that Gates won't be given the chance to choose one or the other - he'll be summarily dumped by the shareholders (who now out-own him 7 to 1) because of his mismanagement of the court case. --
OJ wasn't ordered off the talkshow circuit. To me, the message is clear: killing your wife isn't that bad a thing to do; breaking into a computer is far, far more evil.:-p --
* PC sychronization - traditionally WinCE is kind of blah here, so you'd think this would be a competition point. Instead they don't say much about said syncing. On what OSes will this be supported? (The FAQ mentions Linux, but what about those of us using "legacy" OSes, like, say, Windows?).
It sounds like this machine will have enough brains to run NFS, which makes a pretty kick-ass PDA synchronizer if you ask me. Windows. Hehe. How many people buying a Linux PDA do suppose are not running Linux, at least as dual boot? Anyway, Samba just might work out of the box due to the kernel support.
Will they include PIM software for your computer or do you have to find your own and mess with it?
It seems reasonable to me to suppose that there will be some of both, which is exactly what I want.
* Organizer functions. Does this thing even *have* a To Do list?
Gnomecal is actualy pretty darn nice and could be hacked to fit the smaller form factor better. I imagine there are many other good choices as well.
* Size.
Well, yes, it's a little bigger than I'd like but remember how cell phones used to be? Being just a little bit clunky doesn't keep me from being intensely interested. You should see what happened to cell phone batteries this year. Next year, the same thing will happen to Yopy. But I want to play with this thing now. --
That's very wise;-) If you've been running 2.3.99 you'll know there are still a few "issues" remaining, though these kinds of things hardly stand comparison with the bug list of a certain monopol^H^H^H^H^Hsoftware provider I could mention.
On the whole though, when it is ready, and it's a lot closer than you'd think from the jobs list, it's going to be a real killer. Just a couple of things: Built-in pcmcia and USB; extensive support for video, including USB Webcams; vastly improved SMP support; a new virtual device filesystem that makes major/minor device numbers go away; bags more drivers for all kinds of things; many, many other goodies I didn't mention.
I'll weigh in with a guesstimate of 3 months to 2.4.0 then another 2 months before you see 2.4.x start appearing in distributions. Very, very definiately worth waiting for, or just download it now and use it if you can't wait:-)
Don't forget to put an entry into fstab for shm (shared memory) - this has now become part of vfs, and your distribution won't know about that. --
Sure, it's good that NVidia is paying attention to the Linux market - course at 12,000,000 and growing exponentially they don't really have much choice - but they'd pay a whole lot more attention if you sat this round of NVidia products out and went with Matrox, which reportedly has the best rendering quality in the field, is far from shabby in performance, and has made the fullest release of technical specs so far, which can only result in the best possible drivers. Matrox needs to be rewarded for this, and NVidia needs to learn why secret specs as bad. --
Slashdot Mirror
The only part of this that isn't obvious is why to use IPv6. Actually, that's obvious, too--it's fun to play with new things.
There's a little more to it than that. IPv6 has a much bigger address space - which won't affect you directly - and also has much-enhanced security features and the ability to set up links with predictable real-time performance (IOW it's ideal for Quake).
--
A central configuration system would be neat, but on the other hand you would break compatibility with a lot of existing Unix applications which expect /etc, /proc, and so forth. I guess you could set up this database in a different directory and only new apps would know about it. Better make it flat text, though - I don't think a binary registry will fly very far.
Proc is well on its way to being a registry, except one that doesn't suck. All it needs is persistant storage.
--
And it doesn't scare me at all that Linux apparantly has this goal, because it hasn't nor is it able to replace NT... The problem with you and your fellow advocates is: you don't understand the people you're talking to.
With all due respect, it seems to be you who doesn't understand. Check this out.
This attitude also says to me I never HOPE to be called a Linux User if the loud mouth zealots keep their attitude.
Well then you can make it your mission to do your part to correct this bad behavior and I'll do my part to clue you in on which way the wind is blowing.
--
If Linux would be equipped with a client for win32 (like the client for netware) it would be ok.
;) hahhaha :) that really made my day.
:) I should have said "Microsoft Toady".
No, you just don't get it. Linux is already a perfectly good SMB client - but has greater ambitions - Linux is a great SMB server too, and is also reportedly a darn good NT-replacement domain server (though I haven't tried it myself). If as a MS camp follower that doesn't scare you, then you just don't understand the situation.
Course if you're a user you should be nothing but pleased, because who wouldn't mind having a domain server that costs nothing and doesn't needed to be rebooted once/fortnight?
You apparantly are not well informed and believe that if a person just knows something about win32 he's a microsoft employee
Oh yes, how clever of you.
"Where do you want to go, Toady?"
--
The samba issue is an NT domain issue: a user has to be logged in on a Domain so it gets a Security token that it can use to access other resources within the domain. If you use a Sambaserver and you don't have an NT domain server, you can't use the domain security model (I think that's clear), so that's why there has to be a domain server to use samba.
;-) And I'll put my money on the Samba team's ability to continue cracking Microsoft's secret APIs faster than Microsoft can create new ones. Anyway, by now it should be obvious that the only people lame enough to keep reading this old thread are Microsoft employees and me :-)
Yes and personally I'd prefer that that domain server be running Linux or BSD, which is perfectly possible, and in fact widely done. This works well but there are a few inoperability issues caused solely by Microsoft's hiding of API information, and intentional creation of complex buggy interfaces just to make it harder to create compatible products. Which of course hurts the consumer in a number of ways including make the software more bug-prone and limiting their choice to a single, abusive supplier and an overpriced product.
I dunno, I think if I had to rely on someone's advice I'd go with huusker before I'd listen to you
wishing you good luck with clib
Errr... that's glib. You know, I used to feel like I'd been slimed after every online encounter with a Microsoft employee, but now I feel more like the way I feel after talking to a Moonie - there's a real chance that I may be able to help deprogram them, especially If they've already take the first step by hanging on Slash without being told to do it. There's no preacher like the converted.
BTW, the "g" in "glib" stands for "Gimp", which stands for "Gnu Image Manipulation Program" and Gnu in turn stands for "Gnu's not Unix". Isn't that cool? And plus, "glib" also means exactly tha: it really is a slick library.
--
Microsoft documents Win32 for Windows developers.
Microsoft isn't out there to help competitors reverse engineer their work.
While I have great sympathy for the need of rich corporations (and rich sons of rich lawyers) to become yet richer, I think the general public's need to be protected from substandard products (gas tanks that explode anyone?) outweighs Microsoft's need to keep its APIs secret, which serves no other purpose than derailing attempts to make products that work well with Microsoft operating system but aren't sold by Microsoft.
--
Do you have a more detailed description on how you want this to work?
A good place to start is Newman & Sproul, Principals of Interactive Graphics - check out the section on scanline rendering. The Quake articles written by Michael Abrash are an excellent source, and they go into a lot of useful detail (some but not all of which is only relevant to 3D) To answer somebody else's question, no I'm not an Amiga user but this is just the obvious way to do it. And the corollary is, check out exactly how it was done on the Amiga (I haven't, I'm curious). If the shoe fits, wear it.
Does it increase the amount of memory needed by the server?
No. One of the nice things about scanline renderers is how little memory they use. Of course you can add buffering as an accelerator depending on how much memory happens to be available.
Does it increase the amount of network traffic needed?
It would have no impact on that: exactly the same render commands are sent by the applications. The only extra traffic would be for animation programs synchronizing with the refresh, and that would be miniscule.
How would it cope with for example a Netscape window that was 500 pixels by 100 thousand, which you wanted to scroll smoothly through?
The same way it does now: send a command to scroll the part that doesn't change, clear and redraw the part that does, run the part that goes off the screen into a memory buffer as memory permits. The thing is, all of the transfers to the screen actions would be delayed until the Netscape program says "go ahead and do it". Then all the renders are done, optionally deffering rendering for regions that are not visible, but retaining the commands in case they become visible, (so you don't have to ask the app to regen the region). When it's time to update the screen, you do one of two things depending on whether you have hardware accel or not. With hardware the renderer does a scroll blit and a put blit for the browser window, or multiple scrolls and blits if the window is broken up, but only for the regions actually visible. Without hardware you work your way down the region a line at a time doing the minimal thing to each line, which may be copying it from another part of the screen (slow) copying it from previously buffered data, or putting it from the new render region.
It's also nice to be able to work in an unbuffered mode where all drawing is direct to the screen and the renderer clips each primitive as it's drawn. Needless to say this is much slower and you get flickering, and implementing such clipping primitives efficiently and accurately is hard. But it's very helpful so you can see exactly what your program was doing when it crashed, or exactly why you're getting a messy blob when you should be getting a nice web page. Running the render in slo-mo gives you a graphics debugger.
I've never actually done all this (except in 3D rendering code) so I probably missed a few important points, but I think this is the general idea.
To put all this in perspective, run xpenguins or xroach and notice how much the rendering sucks, and think about what you could do about that.
--
We now come to the fact why people whine about this: they think win32 function equivalents are slow, crippled and crap, and they demand access to the layers below win32 just because they THINK MS' major applications do use these layers INSTEAD of the win32 equivalents.
Well, I don't see how you've addressed Huusker's original point that, among other things, certain key functionality couldn't be implemented in Samba because it's undocumented. How is the Win32 API going to help there? Stop! Don't answer, I'll answer for you: it isn't. So please take your Win32 API and stuff it where the... oh, I mean Win32 just isn't the whole story.
Now, I'd like to say one thing: as soon as I saw the word "whine" in your post your credibility dropped to exactly zero. Why? Because that's a stock Microsoftism, right up there with "innovation". So, all I have to say is "next, please". I asked for someone to clue me in and you're just trying to snow me.
--
I made a quick scan through your paper and it all looks right on the money. We need alpha; we need rotation; we needed zoomable/scalable/rotatable everthing.
I'd like to add a suggestion. 2D rendering is best done much like 3D software rendering: with something like a scanline renderer that makes one pass from top to bottom to render each frame, rendering exactly what needs to be rendered and no more. Instead of depth you have window priorities. Unlike a 3D animation renderer, you optimize for the fact that most of the screen doesn't change at all (so, to respond to another poster's remark - OpenGL isn't the way to go for 2D rendering - it carries too much overhead with it.)
Applications can know or not know about this frame-oriented rendering. If they know about it then can do really smooth animation by synching their erase/redraw cycle with the rendering cycle.
Advantages to be gained are: Software cursors that don't flicker; animation that doesn't flicker; video windows that don't exhibit strange behavior when you drag other windows across them; Scrolling windows that don't have little flickery blank spots at the top/bottom. And you get way, way more possibilities for optimization.
And don't forget this principal: when it's all done it should be smaller and tighter than X is now, even while doing 5 times as much. Because we had time to think about it and factor it correctly.
--
Excuse me for pointing out the blatantly obvious in your post, but none of the APIs you mentioned are used by the Apps team and none of them would require disclosure in a OS/Apps chinese wall.
Remember that applications are written to Win32 and not to the raw NT API hence NTCreateProcessToken(), Subsystem APIs and NTLM RPCs are not part of this.
Also, I've implemented authentication using NTLM over a socket quite happily using the published APIs. Your claim that Netscape cannot do this either implies that the guys at Netscape are fools or they have an alternate agenda. Look at the sample program in MSDN!!
I hate to say it but your post was ill informed, inaccurate and bordering on an outright lie.
John Wiltshire
Now, this debate interests me. Who is right, "John Wiltshire" or Huusker? Someone please hit me with a clue stick.
--
Second, I belive that Sun has released the Staroffice code (though not with an "Open Source" compliant license). How better documented do you need?
Wouldn't it be absolutely the coolest thing if it really was Steve Ballmer? (And I was actually Linus, hehe.)
But who could seriously believe that hands-on control freaks like Bill and Steve could actually resist the temptation forever to go hang on Slash and post pro-Microsoft bafflegab. Not me. I bet each of them has done it at least once.
--
NTLM RPC API Essential for doing DC operations to manage domain accounts. With this Samba could eliminate the need for NT Server. Still undocumented.
I'm pretty late posting this and it's nested pretty deeply so I don't really expect anyone to read this much less moderate it but here it is anyway...
This is the perfect time to sue Microsoft to get the needed api information. Think about it. Little open-source developer (with the help of the EFF) goes after big bad 800 pound Microsoft to get a little itty bitty piece of information that would benefit all mankind. With the opensource world, the DOJ, and needless to say, the supreme court watching carefully. Should they try to put up any meaningful kind of a fight the negative publicity and probable negative legal fallout for Microsoft would be astounding.
Just sue for one little piece of information, get it, and the floodgates will open. Microsoft would never dare hold anything back after that.
--
Really, dear coward, that won't be a problem if it costs $0.50 to download it now. Don't get me wrong, I watch every John Cleese movie and I'll watch this one too, and pay for it. The thing is, it's easy to see the higher price as revenue maximizing, but that's exactly wrong. The way to sell a whole lot of burgers is to sell them for $2, not $20.
This may be possible in some years, but not now!
It's possible now if (1) you have a high bandwidth/low cost connection (many already do) and (2) a payment method is available that required essentially no effort on the part of the consumer, no harder than reaching into one's wallet, and (3) that payment method costs a fraction of a cent per transaction. I repeat: this is possible now, it's just that certain interests are standing in the way of having it actually happen. But someone with the drawing power of John Cleese can make it happen now if it matters to them to be seen as a visionary and not just another mouth feeding at the internet trough.
Note that if the price is too high for downloaded movies, and $5 is too high, we'll just have a nasty repeat of the RIAA fiasco where people are being turned into criminals because they refuse to continue to pay monopoly-inflated prices for artistic content that costs almost nothing to distribute, returning only a tiny fraction of the take to artists.
If you had made the movie you wouldn't be thinking this way. hypocrite.
If you had a spine you wouldn't be posting as an anonymous coward
--
At $0.50 / download it will require 12,000,000 downloads to return 100% profit, not a bad business at all. Otherwise you are paying half what you'd pay to go to a movie for scarcely more rights to it and considerably worse quality.
For these numbers to work an efficient secure means of payment is needed but that's another bloated monopoly getting in the way of the consumer's quality of like.
--
...which is another reason it is not in the 2.3 version
I thought about it some more, and I realized that the principal that must apply, classically, "no news is good news". You are right to remove these messages. They shouldn't appear during package installation either. And there should be no code in the kernel module devoted to providing an option. That just takes up memory.
All the same, reading the credits gives me a warm and fuzzy. I just don't want it mixed in any way with the machinery of the OS. One excellent place to give credit/blow one's own horn in the package info of an RPM, as long as it's not too obtrusive and doesn't get in the way of the functional information. Another good place is in the usual CREDITS file that's often included in a package distribution. Do we need any more advertising that this? I really don't think so. As you said (more or less) being able to take credit on *one* web site that you own is worth many 1,000,000's of little boot nags.
--
Actually I'm torn on whether I like them or not. These particular messages are certainly unobtrusive, modest, almost self-effacing. But still, it has nothing to do with how the computer boots. But still but still, I wouldn't mind having a generic place to put splash-type info, both for text mode and graphics, and some times I'd want to see it just out of interest. Especially the first time I boot a new distro.
To make sure this splash stuff stays informative and doesn't get irritating we need a generic way to turn it all off, and that method has to act early in the boot sequence. That means it has to be some kind of kernel flag, and everybody who wants to put in non-functional information (e.g. credits) has to use it. This would require a fairly broad concensus...
--
Now try to fing a job e.g. in the finance area with your wonderful Qt of GTK+ experience.
If getting a good job is your only motivation I suggest you bill yourself as a Java programmer - you'll earn more and probably get more projects completed than as an X hacker.
If you insist on building enterprise apps in C then use a Unix port of GTK, or pay for the QT licence - you can afford it. Motif is certainly a PITA to program but certainly is certainly the more powerful toolkit of the three. One thing that I can't stand with GTK+ is that preferences are host centric and not display centric... That's plain stupid, I can access the same app from many displays and certainly want preferences specific to the display, what if one is small and B&W and the other large and TrueColor, I certainly don't want the same font size and icons on both...
Thanks for pointing that out. I never noticed it in practice but I can see why you'd want that. I can think of more variations: sometimes I want my prefs to be specific to something very application-dependent, like a URL (just hate those sites that put teensy fonts on their web pages). I wonder how that could be handled elegantly. I'm sure we'll find a way.
GTK+ completely lost the network part of X... If I want a non network centric window system I can simply use Windows...
Err... no. GTK works perfectly well remotely - I was using it that way two nights ago, with the client running on Win NT no less. It gets this for free by running on top of X.
--
Nedit
--
There's been a lot of speculation about whether being broken up would make the sum of Microsoft's parts more or less valuable than the whole. Personally I think: Not.
Microsoft's market machine so far has acted like a nutcracker - squeezing customers and competitors alike between it's two jaws: control of application api's through the os on the one hand and control of competitive os's through the apps on the other. Breaking Microsoft into two parts will be much like removing the nutcracker's fulcrum. You may still be able to poke people with iether half, but can no longer break their nuts^H^H^H^H^H^H^H^H^H^crack nuts with it.
Without their made-in-heaven monopoly machine to fuel their unbelievable profitability there's only one direction for their earnings to go: down.
Microsoft's market cap is based on expectation of unending growth at a rate serveral times that of the computer industry as a whole. To date that fairytale has come true, year after year for more than 20 years. No longer. First, their earnings aren't going to grow any more, their going to shrink. Second, Ballmer is right - the rats^H^H^H^H^Hbrains are getting out. So are the execs. For the simple reason that Microsoft's options aren't worth a whole lot any more.
On that subject, absolutely the worst thing that could happen to Microsoft is a long slow decline in their stock price. This would be much more harmful that, for example, a sudden drop by a factor of 10. The reason? The long slow decline means that Microsoft options will never be worth a cent. Whereas if their stock would just fall into the basement and get it over with they could possibly once again use options as a useful tool.
There are other factors that will stress Microsoft's share price. Not the least of which is the availabilty of at least one superior alternative that costs nothing (or something, it's your choice). There is only one possible result. Microsoft will have to do major surgery on it's OEM prices and that means "goodbye 95% gross profit margin". In turn meaning more decline in the stock price.
And don't forget the upcoming class action suits, and the still-to-be-filed damage suits from competitors that suffered from their illegal practices.
All these troubles would be multiplied if any evidence of financial misrepresentation turns up.
OK, enough, enough. Time for my prediction. I predict that Microsoft's market cap will fall to less than that of General Motor's, which is somewhere in the $50 billion range. That means a further factor of 5 fall from where they are now. I predict that it will take a year to fall that low as shareholders really begin the understand the implications of losing at trial and being beaten by a free OS at the same time.
In the long run I don't see a lot of value in the Baby Bill's. I see the office monopoly eroding quickly, and I don't see the underlying problems of the software being fixed. I don't see Microsoft's good name ever being restored, nor Gate's. In short, I see Microsoft's total value falling to less than, for example, CA's, in other words, it's going to be decimated.
Well, Bill, it's going to be tough for you to swallow but sincerely believe you went out of your way to earn this.
--
I'll go out on a limb and say that Gates will choose to abandon the OS company (calling it Windows), and go with the apps company, which would retain the Microsoft name.
I'll go even further out on a limb and predict that Gates won't be given the chance to choose one or the other - he'll be summarily dumped by the shareholders (who now out-own him 7 to 1) because of his mismanagement of the court case.
--
OJ wasn't ordered off the talkshow circuit. To me, the message is clear: killing your wife isn't that bad a thing to do; breaking into a computer is far, far more evil. :-p
--
* PC sychronization - traditionally WinCE is kind of blah here, so you'd think this would be a competition point. Instead they don't say much about said syncing. On what OSes will this be supported? (The FAQ mentions Linux, but what about those of us using "legacy" OSes, like, say, Windows?).
It sounds like this machine will have enough brains to run NFS, which makes a pretty kick-ass PDA synchronizer if you ask me. Windows. Hehe. How many people buying a Linux PDA do suppose are not running Linux, at least as dual boot? Anyway, Samba just might work out of the box due to the kernel support.
Will they include PIM software for your computer or do you have to find your own and mess with it?
It seems reasonable to me to suppose that there will be some of both, which is exactly what I want.
* Organizer functions. Does this thing even *have* a To Do list?
Gnomecal is actualy pretty darn nice and could be hacked to fit the smaller form factor better. I imagine there are many other good choices as well.
* Size.
Well, yes, it's a little bigger than I'd like but remember how cell phones used to be? Being just a little bit clunky doesn't keep me from being intensely interested. You should see what happened to cell phone batteries this year. Next year, the same thing will happen to Yopy. But I want to play with this thing now.
--
So WHAT does it stand for???...
Drawing on my somewhat limited knowledge of Korean, I'll take a wild guess that it's a diminution of Yoposaeyo "Hello, are you listening?"
--
I'm not holding my breath for 2.4
;-) If you've been running 2.3.99 you'll know there are still a few "issues" remaining, though these kinds of things hardly stand comparison with the bug list of a certain monopol^H^H^H^H^Hsoftware provider I could mention.
:-)
That's very wise
On the whole though, when it is ready, and it's a lot closer than you'd think from the jobs list, it's going to be a real killer. Just a couple of things: Built-in pcmcia and USB; extensive support for video, including USB Webcams; vastly improved SMP support; a new virtual device filesystem that makes major/minor device numbers go away; bags more drivers for all kinds of things; many, many other goodies I didn't mention.
I'll weigh in with a guesstimate of 3 months to 2.4.0 then another 2 months before you see 2.4.x start appearing in distributions. Very, very definiately worth waiting for, or just download it now and use it if you can't wait
Don't forget to put an entry into fstab for shm (shared memory) - this has now become part of vfs, and your distribution won't know about that.
--
Sure, it's good that NVidia is paying attention to the Linux market - course at 12,000,000 and growing exponentially they don't really have much choice - but they'd pay a whole lot more attention if you sat this round of NVidia products out and went with Matrox, which reportedly has the best rendering quality in the field, is far from shabby in performance, and has made the fullest release of technical specs so far, which can only result in the best possible drivers. Matrox needs to be rewarded for this, and NVidia needs to learn why secret specs as bad.
--