Reading the article I find some things weird, perhaps it's me, but here they are:
The article starts bragging about internet and Linux is a child of the internet blabla... It gets me the 'Al-Gore feeling: I invented the Internet!'. This is kinda weird and not on it's place IMHO
First Linux is mentioned as a prominent subject and then OpenSource comes to the table, the OpenSource concept is important, but what's the link with naming linux in this picture (besides it's an open source project) ?. Seems to me for VA Systems Open Source == Linux, while it's not, IMHO. Linux is just a product of the Open Source community, just like my small ASE parser is.:)
I think they should change the slogan 'news for nerds, stuff that matters'. There are a lot of nerds who are not using linux but are still proud to be a techie, a nerd, a geek. With the 'Linux' word mentioned more than once in the article, a true nerd who is not using linux BUT open source software is going to feel him/herself a little orphaned by this site. Don't shout this is a Linux site, it's especially an open source site. read point 1.
To me, the discussion element is part of the sitesystem, not part of the name/. so I think if the articles to discuss about are more and more focussed towards a certain topic (like NOT anti va-linux or linux in general) more and more people will abandon this site and move to alternatives.
If there are any left, where geeks and nerds of all different OS-es and programming languages can discuss the stuff that really matters and which is not typically fitting in a (VA)linux world...
The TNT doesn't support a HW stencil buffer in 16bit rendering mode. (only in 32bit). Perhaps you tried it in 16bit mode. The opengl support is ok, on win32 and also on other OS-es afaik. But not that 'excellent', its drivers skip opengl standards sometimes (like crashing on a NULL pointer, while the standard states it should return an error, or like ignoring GL_POLYGON_SMOOTH, because it can't do it in hardware and it would slow down anyway).
You don't need js to lock up a system via a browser.:) (Use a lot of nested tables in cells in a page. netscape will allocate a LOT of memory and use a lot of CPU cycles:)
Javascript is a tool to get extra functionality at the client. IMHO you should use it as less as possible, but it CAN be handy sometimes. It's however a problem nowadays with the functionality added to the browser that is misused by sick minds.
Disabling javascript is not the solution IMHO. Keeping up to date with the patches is.
I know this works (I just tried it in IE5), but I can't think of any security issues here. Can you please explain why this is a security issue (the about thing). As far as I can see, the html (even malicious) is parsed but you can never execute commands with it outside the browser. Or am I wrong? (and IMHO the about thing isn't a bug, it's a feature (honest):)
Most countries have a law that protects 'intellectual property'. Everything a person makes/creates/or delivers as a result of his/her own actions is protected by that law, UNLESS you signed a contract that TRANSFERES that right to use that law to an employer or other person you signed the contract with.
If some person is the owner of the intellectual property you want to use, you can never state it's yours. This means, if the person who owns the intellectual property, wants money for it (like the GIF compression algo), you HAVE TO pay. This is no SHITTY thing or a lame crooky monopolistic action, it's the law and everybody can profit by this law.
If you have accepted any kind of license of the program you reverse-engineered, and that license states you are NOT allowed to reverse-engineer it, you broke the law. As simple as that. No whining about 'if it's right or wrong', that's another story. The law says 'X' so 'X' should be done. If you want it to be 'Y', elect a person who will change the law. That's another story.
So it's pretty simple to determine if you broke any laws or if you are going to break any laws. By reverse-enginering a piece of software you probably broke the law already, so your case is weak. Get a good copyright laywer to check if you broke any laws and if you're going to by publishing perhaps patented and protected intellectual property.
Note to the whiners about if this is right or wrong: there ARE people on this earth making money by writing software, hell I think a LOT of the/. readers DO. These products are protected by law and by licenses. If we let people break laws and licenses who are perfectly clear, what's left? What's the difference between stealing intellectual property from a person who is under NDA and by reverse engineer a certain product? (chip, logic circuits, software etc).
Ok, some thoughts, after reading the texts of a lot of people here:
The formats for the various media are developing in a high speed. Today, MS has the best compression/quality factor for streaming audio, but that can change tomorrow. We are at the beginning. So, a lot can happen within half a year, because the current quality of streaming media is not up to par as we all would want
MS isn't the only company creating a streaming media library. On the contrary. The others are also closed source and not willing to open up the source code. And that's obvious: if you do, everyone can use the software for free. And especially the serverside codecs are important for linux. Free serverside codecs smashes the income stream (pun intended) for Real, and in less way also for MS and Apple. It's just business.
Plus: with that amount of servers around the world, why isn't the Open SOurce community simply developing Server side codecs AND clients for various platforms? If it's free, not that much people will bother downloading an Open SOurce variant or a closed source variant.
YOUR attitude is the reason why more and more people will turn their backs at Linux. Do you really think a company will let itself in with a group of whiners and yellers like you?
I guess not. I KNOW they won't. A lot of people communicate on a MATURE way with others, and make Linux look good. You and your fellow whiners do not, and burn that reputation down to the ground.
This is a geek site. A Site for computer and software lovers, and you can be a geek also when you use another OS (it's a program for ()&*$#(@&*#$@ sakes) than your OS of choice.
One single reply on a talkback forum on a fudsite tells that it breaks something else.
That's a really reliable source to me.
If you'd have looked deeper into the problem, you'd have known you could have protected yourself easily the way you already SHOULD have protected yourself: with removing all the extensions NOT NEEDED by the websites on your server. It's simple. It's even stated in the idiot-proof security manual by MS;)
So if you did everything right, you'd have used ASP for the indexserver queries, and you'd have deleted the idq/ida extensions:) (together with all the other extensions like htr etc. rememer that bug?:)
the.ida and.idq bugs are in a dll that's depricated. No good developer will choose the old schema of idq and htx files to get indexserver results, but will use asp for that. So the extensions can be removed from the webserver and no patch is needed.
Checks to see if the bytecode for Foo already exists, and if not it loads it, verifies it, and calls the class init method. This is very very slow, but should only be done once.
Allocs new memory. Probably very quick
Calls the hierachy of constructors of all Foos superclasses. Quite slow.
(For advanced garbage collectors) Place the object on the 'recent items' list. Probably quick
Well... Don't forget: you live inside your virtual machine. it's not Native Java On Your Pentium System. Creating a new instance of an object is implemented slow in the JVM, perhaps because it doesn't use a heap. If the JVM needs extra money for the object to create it first has to allocate new memory for itself, then it has to assign it to the object inside the JVM. it's two steps where 1 is enough. That's the evil of emulation. An inner loop optimalisation with a JIT can be faster sometimes (I've seen some 'test' programs that should prove a Java JIT is faster than a C compiler. All these programs did was run some for() loop a zillion times.), but only in small area's. (Today).
A program that uses a JIT compiler can perhaps execute faster AFTER the JIT has ran, but the JIT takes away execution time. The MORE optimalisation you do in a JIT the more time it consumes. The weird part is: the JIT's we know today don't store their compiled code. Why not? Ok, some optimalisations are part of the executionpath the program takes based on the actions and reactions of the user, but a lot of stuff is not.
Interpreted languages have the disadvantage that the result of the interpretation is lost. A JIT solves that (partly). The old discussion about whether a true native compiler can generate code that is faster than the code interpreted and compiled on the fly with a JIT, is a discussion that's not closed or won by any part. This is because there is no scientific evidence that proves any side is right (yet).
What we KNOW today is that a native compiler can generate code that is, generally speaking, fast on the target CPU. Faster than the interpreted version. We also know that the compilers of TODAY can't always predict what's the most fastest code to emit. the optimalisation schemes are very clever but not clever enough. We know that some optimalisations can only be done at run time when there is knowledge what to avoid and what CAN be optimized.
It's thus a mixture of both. However, as I said before, the addition of a JIT to a native compiled codepart, as can be done in a CPU, also adds CPU time. It's thus up to the JIT developer to keep the time added by the JIT lower than the gained speed:) This is sometimes the case, in other situations there can be a lot of CPU time lost to the JIT, because code is just executed once or twice.
Besides the technical aspect: what's really important? if you want platform independance (hardware wise for example), what are you willing to pay for that issue? speed in execution? a high price in software?
If speed is the most important thing, emulation and JITs are TODAY not an option. Perhaps tomorrow or next year, when there is more information available about what is faster in certain situations: a CPU with a JIT, or a JIT with interpreted code or just a fast CPU with native code.
Take a newbie and get him started on D3D. Take another newbie and have him use OpenGL. Who will have working code sooner? the OpenGL newbie will definitely have a rotating polygon sooner. But that's not the point I was refering to:) You see: perhaps the learning curve of d3d is steeper than OpenGL's, but in the end if you want to program a full application and you need all the API's power to achieve good quality, it takes the same amount of time and effort to get there.
Once you need to start worrying about Visible Surface Determination, the API isn't the bottleneck: Your culling / occlusion algorithms are, along with state minimization, and texture management. Wouldn't you agree? I agree. It's however funny to see people first don't understand statechanges are expensive and visual face determination IS important:). I think that the understanding these things are important is part of the learning process of both api's. The api's both provide different solutions to achieve the same goal, but the goal first has to be determined by the programmer. newbies never get that:)
For the most part it is. I'm curious, what part of OpenGL isn't orthogonal? For me: display lists: it's a whole bunch of hoopla but no speed increase nowadays, and the global orientation of the code: it's nice to have everything global, but it can also work against you, especially in a OOP environment IMHO.
MS shoved D3D down our game developer throats whether we wanted it or not. OpenGL works for games, as Carmack has shown us. They already had OpenGL on NT, why did they have to go and FIX ANOTHER API? There were numerous api's. Not one was 'major', perhaps Glide was. MS created DX (not only D3D) to provide a uniform layer of abstract code using COM, which was always the same, independant of the underlying hardware. It solved a problem for gameprogrammers: which api would we take? Glide? MeTal? OpenGL? Not one of these was supported by ALL cards. D3D is. For gameprogrammers this was a blessing because they could now focus on 1 API.
The D3D drivers are very small, because the HW vendor just has to implement the very basic stuff to communicate with the hardware. The rest is already implemented in the HAL. That's why it's easy to provide a good d3d driver, the opengl icd has to contain that HAL AND the HEL and the driver.
Question: How does a vendor provide extensions in D3D ? Oh wait, they CAN'T, unless they pesister MS to provide it in a future D3D version. Afaik, Dx7 also contains an extension mechanism.
OpenGL is WAY easier to use then D3D. This is of course very dependant on your skills in the area of the API. If you don't get Binary Objects, if you don't understand OO, you'll NEVER understand D3D. It will be very hard then. OpenGL is a difficult API to master as D3D is too. Everyone can cook up a spinning cube, not everyone can cook up a 10.000 poly world running at decent framespeeds with a lot of different textures.
OpenGL is orthogonal. SGI had tons of experience with IrisGL before they cleaned it up and "re-named" it OpenGL. Well, there are still some IrisGL leftovers in the OpenGL that should have been removed already. Some things are odd in OpenGL, I wouldn't call it orthogonal:)
OpenGL has a consistent design (look at Direct3D having 7 versions in 5 year!) OpenGL has gone thru 2 iterations in 10 years. Does that mean OpenGL has been slow to change? No, as vendors are allowed to add any extenstion they wish. Sorry to interrupt your dreams, but OpenGL seriously is moving forward WAY too slow. I mean by this that the 1.2 specs are great but they are great for a long time already. It's now official and finally we begin to see 1.2 compliant subsystems, but it took way too long, so currently a lot of subsystems don't support any nice features which are provided by the hardware. If the standard would have forced the functionality earlier, Matrox and S3 would have been forced to implement more functionality than they did today. NO Matrox OpenGL driver NOR S3 OpenGL driver supports ANY features which make these cards outstanding: the Matrox bumpmapping in the Gxxx series and the S3 texturecompression. Sure, extensions have an advantage: vendors don't have to wait for the library supplier to release an updated version, but it also doesn't force vendors to add the features.
D3D is a young api. OpenGL is based on IrisGL. Every new technology has it's problems when it's created. IrisGL had these too. D3D is up to par now. It's however IMHO not correct to say: D3D is crap because they had a lot of version in a short time. That's BECAUSE it's new.
OpenGL also has a conformance test, guaranteeing that all OpenGL implementations are feature complete, unlike D3D. Does that guarantee speed? No. Drivers are allowed to "fall-back" into software. Feature complete is somehow a bit stupid here. 'Feature complete' refers to the 1.1 or 1.2 featureset. 1.2 is too new to be very common, and 1.1 is very old. To be 1.1 compatible doesn't say a thing nowadays. For example ARB_multitexturing, a MUST HAVE feature today, isn't in the 1.1 set. The software fall back is a thing that annoys me the most on OpenGL. When I do a glEnable(GL_POLYGON_SMOOTH); on a GeForce card, it falls COMPLETE to software, because it can't do a part of the pipeline in software, but in D3d only parts of the not by hardware supported features, are done in software. That's IMHO a better approach.
... because of some "politics" 3D accelerated graphics card vendors are prefering iplementing DirectX acceleration Thats because Microsoft IS so bull-headed after buying Direct3D from Rendermorphics I can only laugh about this.:) Man, do you really believe this is the issue? If you know how d3d drivers are developped, you'd know that a vendor can create a d3d driver for his card with a very small piece of code. So a vendor can easily create D3D drivers for his card, which means there are _always_ d3d drivers for a certain piece of hardware. An OpenGL ICD on the other hand takes a lot more time, because the vendor has to write the complete renderpipeline in the ICD. Ok, they get a basic framework from SGI, but still.. it's a lot more work. In the past, vendors just didn't release any ICD because it would cost too much (S3 comes to mind), but today thankfully any decent cardmaker releases an ICD. It's however a shame not all of those cardmakers include all the new HW features in the ICD via extensions as nVidia does.:(
Take care... DemoGL main developer. DemoGL is a win32/OpenGL multimedia library.
The 'MS' camp can't be, so it SHOULD be Novell. As a microsoftie (yeah flame me, I don't care) I laugh about the 'case studies' MS puts up to proof another product is bad/wrong/whatever. Whoever goes for that crap is truely in the wrong profession. Same goes for the other company's marketing departments and their mudthrowing 'Case Studies' about the products of the competition. You fall for those too?
I hope not:)
For the people who already know what's right and what's wrong: beware what you believe. Think who spread the texts you think is right. Is it the company or is it the techteam working on the product?
About the NDS vs AD debate. NDS is already out there for some time now. It wasn't up to par when it saw it's first light, it seems to be usable very well in lots of environments. So people get used to it, know it's strengths etc. AD on the otherhand isn't even out there. It's not even released. No-ONE has seen it. Only selected testers who got RC3 (and I don't think a lot of them are reading/. all day;)). The rest of you is making his judgement on the quality of AD on what's written in the press, and especially on sites with doubtable reputations like ZDnet.
Novell fights for every percent marketshare they can get. It's their right. For people who have to use products from both companies, MS or Novell, it's better to test out what's there, and judge for ourselves.
And that is only possible AFTER Feb. 17. Or did you all do excessive tests with AD on a serverfarm full with win2K server machines and numerous clients and also the same test with NDS?
I'm an MSCE too (9 certificates) and I think the domain model is great. DNS is a static system, which should be removed a long time ago. These 2 things are not related really. The domain system used in NT is not usable on the internet and vice versa.
Because you hate it and I love it, makes it even I think. Your opinion is biased by your personal favor. That's totally ok, but not usable in a discussion.:). NDS is ok, you say it's FAR superior to AD. Ok, let's have it then. throw it out in the open and explain WHY it's so incredibly far more superior.
About kerberos, you're correct. It was a dumb phrase of me to call it encryption. It's a system to secure authentication like lanmananger protocl is, ok. I ment that, I used 'encryption', which is of course not the case. It's however a step in the good direction to let go the lanmanager protocol and choose something that is already implemented and has proven to be ok (at least to be better than what's there today in NT;). Implementing it with bad code is of course the nail on the coffin of a secure NT system. What I ment to say with my zillion lines is that IMHO MS has learned from the past (so history IS important but not in a way to prove the future will be bad as well) and will commit itself to a more secure environment so the weak spots are not due to weak software as demon also pointed out and we all know was true for a few years in NT land. The topic is/was if MS will commit itself to a secure OS, and I say, looking at what they've put into their new OS plus what they've done to make NT 4 secure... yes, they will.
But time will tell. IMHO they've tried hard enough. Open source IMHO wouldnt have made it any better, because a lot more developers have looked at the code outside MS (for example a lot of developers at IBM have), than before. Ah well...:)
I'm a programmer, worked on both unix and NT for years, not administrated them (well NT I did, only admin on AIX a few years back). I won't say history is meaningless, every day we learn it is not meaningless, but in productcycles, you can't predict the quality of a future product, looking JUST at a history record or lists of bugs in the early days.:). If the software is flawed, it's of course undoable to make it work 100%. IMHO if you throw up as many steep hills as possible, it's almost undoable for a hacker to break in. It must become uninteresting for a hacker to go on. I think then you can cover the last bit of percent all systems indeed lack in total security. I'm glad MS finally is aware that the market is not waiting for lots of NEW stuff, but actually WORKING stuff. Which also means the tools to make it secure. (so it's the admin's fault that there is a hack).
Only time will tell if they are right. no history can IMHO.
Long posting... Main line of my posting: nothing is secure, you have to make it secure yourself. So that means, I'm not saying NT is more secure than anyting else or anything else is more secure than NT. (offtopic discussion, btw.). Few things: about the security fixes... the few security leaks in NT in 1999 were patched within a day or 2 and downloadable for everybody. And about the history.... my point was: the history of NT when it was first released and with the bad servicepacks 2 and 4, is not necessary true for the future. You USE that history to make it look bad, while from your text I can IMHO conclude you don't have a lot of experience with administrating NT server. That's not bad, but calling it bad, plus it's security bad, BECAUSE history tells you so, is IMHO a bit shortsighted. It doesn't matter which OS, if the admin is sloppy, the system is insecure.
tell me, why would I believe you, that MS told a lie, and not MS? because they are liers, right? I've been reading and posting to that guestbook on www.windows2000test.com every day during the test. They had found some severe leaks in the tcp stack, some crappy bugs in the script, some DoS results, but after a month... all were gone... no attack gave any result. Ok, you obviously won't believe the statistics they posted every day about the amount of DoS packets or hack attemts the server received, but it was an awefull lot. They were very informative when the server was down or when they found a bug or when the server was crashed (it crashed a couple of times in the debugger). Also think about the fact that no firewall was there, every spoof package was passed through. Sure, any unix server which was setup by a security professional, would have survived it too, but just because there weren't any security leaks reported, as people breaking into the server, doesn't have to mean MS is lying.
After all, it was a technical test. They do that too, you know.
G: Well, you have to have exp... You know, if somebody's camouflaged the thing pretty well... That's a question of fact, not of law. The question is, did they borrow from my work, okay? [...]
Interesting subject, because... what if you port GPL code to another programming language, or better, you snip out a part of the code and recode it because you use the idea behind the code, in your own code. Borrowing, or theft and THUS voilation of copyright law because voilation of the GPL... any thoughts?
Ok, I read the standard replies on any MS related article, filtered them down. Then I read some postings with the most stunning remarks ever: NT's security is NOTHING like you'll find on linux or any other unix or similar. Whohoa. On what kind of fact is this based?? On the fact Unix's security is based on 1 superuser which is needed for all daemons? on userrights instead of object rights?
To me it sounds like people who rate NT's security as 'lame and nowhere the level of security on Unix is' really don't have a clue about how NT's security works.
Let me sum up a small list of items, related to the topic. This is not ment for a flamebate, but to let unixpeople learn it's not windows 9x we're talking about, but NT/windows2000.
NT is in the US/Canada area already 128bit for years. Windows 2000 will be using 128bit security worldwide.
NT 3.x and 4.x uses the weak NTLM protocol. It could be tough to break but in areas outside US/Canada, the encryptionkey was too short to hold long. Windows2000 will use Kerberos strong encryption, which is an industry standard. Poking at MS that their encryption is weak (especially in their upcoming product) is without ground, because Kerberos is a proven secure technology.
NT uses security throughout the system on objects. It's then way more flexible to set security flags, without the necessity to open up the system because a certain daemon needs root access, for example.
MS fixes security leaks within 24 hours most of the time. Arguing it takes ages to get a fix are therefor unfounded.
In the past year, there were some minor security glitches in NT itself. The security bugs in IIS are due to leaks in modules that IIS uses, not IIS itself, like the idq.dll module for old style indexserver queries. Today you don't need these modules. Still, unskilled administrators install the basic set. Like unskilled administrators will with RedHat 6.x on their hands. That's why there are idiotproof docs to guide these (majority, unfortunately) people.:)
IE holes are a problem, but who surfs the net on a production server.
MS provides a bulkload of security documents how to implement security on your servers. These are perhaps silly for die hard techies ("Duh! don't install the examples!!"), but MOST of the system administrators, ALSO on unix, are not people with 10 to 12 years of experience with administrating servers. Don't forget that. Most sites which are hacked are setup by not well skilled people. Pointing at the OS is silly. No-one says unix is unsave because sendmail is crap. the administrator should be aware that the sendmail on his system is likely an older version than available today.
Which brings the last and most important subject to the surface: if you don't follow the security sites, if you don't apply patches REGULARLY!, if you don't know what to close and what to remove from the system to keep/make it secure, and most important: if you DON'T let a 3rd party, specialized in security, scan your systems for leaks, your system won't BE secure, no matter what kind of OS you have. Admitted: some OS-es have LESS open doors than others, but NO OS has NONE closed doors. Don't forget that.
NT 4 was a wise lesson for MS. They have it on track now, but it has been a long road. It's nowhere near the end, there are still areas for improvement, but these are there too in other OS-es, like Linux or *BSD. Being aware of the weaknesses of your own system is a Good Thing (tm). You can then secure it more. Blinding yourself with talk that only MS makes insecure stuff is silly. Ask all those Solaris administrators currently suffering the DoS worms:-/
Bashing the FUTURE without knowing what it will bring (have you all used Win2K server??? have you tested the security???) with the facts of old material from the past is not fair. If you turn around the roles and people will bash Linux using the hundreds of holes in all the distributions which were found in the last 2 years and say: "linux is not secure... because of all those leaks in it in the past years." is that fair? I'm pretty sure you'll say: "No!".:)
You are right about we should focus on the real red line in the article, which is about a VM solution in FreeBSD. However, the fun gets spoiled by more than 20 lines of TOTAL UNNECESSARY craptalk about what's bad in this and buggy in that. Because the mudthrowing of Dillon is in his article, I can comment on that in this forum. He might have achieved a lot in this world, he still has to OR 1) pay respect to others who also have achieved a lot in this world and work also very hard and thus focus on the subject of his article and leave the mudthrowing to others OR 2) point out WHY others are bad and buggy when throwing mud.
He chose the 3rd option: throw mud and hope for the right audience who will love him for that mudthrowing. Well, some will, other won't. And that's sad.
Because what would have been REALLY interesting is: the NT model of threads attaching to loadable libraries in core and how NT solves the problem mapped on how FreeBSD solves the problem with processes, not threads, because he focussed the reader on the NT topic as being crappy because it has flaws that were solved decades ago in Unixland.
. I read you ask for respect for mr. dillon and for not being immature. Well, I can only answer: I don't respect people who throw mud at others without pointing to the reasons why. That means: you MAY throw mud on others, but explain why. If you don't, you are just the same as the people you describe, a teenage male looking for yet another venue to release their now trendy, "geek angst".
The article itself was pretty straightforward and insightful. Insightful because it let you look into the kitchen of FreeBSD without you have to crawl through lots of code. That's a Good Thing (tm). It wasn't really 'new' or '21st century tech' to me. Because IMHO a process fork() is something a modern OS shouldn't do, but instead spawn threads.
Re:Hard to know much about closed-source NT!
on
FreeBSD VM Design
·
· Score: 2
Mr Dillon knows more about FreeBSD than anyone outside Microsoft can know about NT do these things relate? Back to the topic: if NT is packed with errors solved in Unix a decade ago, relating this to the actual topic of the article, are there designflaws in NT's VM handling? Don't come out now with the words 'we don't know! we don't have the source!!', because that's bollocks. There are numerous documents written by a lot of people about NT's internal structure and also about the VM handling and specifically connected with threads (the buildingblocks of NT's multitasking, Unix uses processes as building blocks). So, in the light of the article, what is so incredibly wrong? Mr. Dillon makes the, IMHO not so clever, remark that NT contains flaws unix doesn't have. So I say: which? because he MAKES the remark, he KNOWS what's wrong, right? otherwise how can he say THAT there is something wrong... that was my point. Perhaps offtopic, whatever, and already moderated down because it's perhaps hurting for the OS OS people here, but I just want to know.
Slashdot Mirror
- The article starts bragging about internet and Linux is a child of the internet blabla... It gets me the 'Al-Gore feeling: I invented the Internet!'. This is kinda weird and not on it's place IMHO
- First Linux is mentioned as a prominent subject and then OpenSource comes to the table, the OpenSource concept is important, but what's the link with naming linux in this picture (besides it's an open source project) ?. Seems to me for VA Systems Open Source == Linux, while it's not, IMHO. Linux is just a product of the Open Source community, just like my small ASE parser is.
:) - I think they should change the slogan 'news for nerds, stuff that matters'. There are a lot of nerds who are not using linux but are still proud to be a techie, a nerd, a geek. With the 'Linux' word mentioned more than once in the article, a true nerd who is not using linux BUT open source software is going to feel him/herself a little orphaned by this site. Don't shout this is a Linux site, it's especially an open source site. read point 1.
To me, the discussion element is part of the sitesystem, not part of the nameIf there are any left, where geeks and nerds of all different OS-es and programming languages can discuss the stuff that really matters and which is not typically fitting in a (VA)linux world...
The TNT doesn't support a HW stencil buffer in 16bit rendering mode. (only in 32bit). Perhaps you tried it in 16bit mode. The opengl support is ok, on win32 and also on other OS-es afaik. But not that 'excellent', its drivers skip opengl standards sometimes (like crashing on a NULL pointer, while the standard states it should return an error, or like ignoring GL_POLYGON_SMOOTH, because it can't do it in hardware and it would slow down anyway).
Aint the current linux drivers up to par?
You don't need js to lock up a system via a browser. :) (Use a lot of nested tables in cells in a page. netscape will allocate a LOT of memory and use a lot of CPU cycles :)
Javascript is a tool to get extra functionality at the client. IMHO you should use it as less as possible, but it CAN be handy sometimes. It's however a problem nowadays with the functionality added to the browser that is misused by sick minds.
Disabling javascript is not the solution IMHO. Keeping up to date with the patches is.
I know this works (I just tried it in IE5), but I can't think of any security issues here. Can you please explain why this is a security issue (the about thing). As far as I can see, the html (even malicious) is parsed but you can never execute commands with it outside the browser. Or am I wrong? (and IMHO the about thing isn't a bug, it's a feature (honest) :)
the basic crap was part of the fun ;) ah well ;)
10 print "In reality I'm an obfuscated version of msvcrt.dll"
20 goto 10
So it's pretty simple to determine if you broke any laws or if you are going to break any laws. By reverse-enginering a piece of software you probably broke the law already, so your case is weak. Get a good copyright laywer to check if you broke any laws and if you're going to by publishing perhaps patented and protected intellectual property.
Note to the whiners about if this is right or wrong: there ARE people on this earth making money by writing software, hell I think a LOT of the
Plus: with that amount of servers around the world, why isn't the Open SOurce community simply developing Server side codecs AND clients for various platforms? If it's free, not that much people will bother downloading an Open SOurce variant or a closed source variant.
Ah well, here goes another karma point.
YOUR attitude is the reason why more and more people will turn their backs at Linux. Do you really think a company will let itself in with a group of whiners and yellers like you?
I guess not. I KNOW they won't. A lot of people communicate on a MATURE way with others, and make Linux look good. You and your fellow whiners do not, and burn that reputation down to the ground.
This is a geek site. A Site for computer and software lovers, and you can be a geek also when you use another OS (it's a program for ()&*$#(@&*#$@ sakes) than your OS of choice.
One single reply on a talkback forum on a fudsite tells that it breaks something else.
;)
:) (together with all the other extensions like htr etc. rememer that bug? :)
That's a really reliable source to me.
If you'd have looked deeper into the problem, you'd have known you could have protected yourself easily the way you already SHOULD have protected yourself: with removing all the extensions NOT NEEDED by the websites on your server. It's simple. It's even stated in the idiot-proof security manual by MS
So if you did everything right, you'd have used ASP for the indexserver queries, and you'd have deleted the idq/ida extensions
the .ida and .idq bugs are in a dll that's depricated. No good developer will choose the old schema of idq and htx files to get indexserver results, but will use asp for that. So the extensions can be removed from the webserver and no patch is needed.
:)
Ah, well... the mud flies already
Well... Don't forget: you live inside your virtual machine. it's not Native Java On Your Pentium System. Creating a new instance of an object is implemented slow in the JVM, perhaps because it doesn't use a heap. If the JVM needs extra money for the object to create it first has to allocate new memory for itself, then it has to assign it to the object inside the JVM. it's two steps where 1 is enough. That's the evil of emulation. An inner loop optimalisation with a JIT can be faster sometimes (I've seen some 'test' programs that should prove a Java JIT is faster than a C compiler. All these programs did was run some for() loop a zillion times.), but only in small area's. (Today).
A program that uses a JIT compiler can perhaps execute faster AFTER the JIT has ran, but the JIT takes away execution time. The MORE optimalisation you do in a JIT the more time it consumes.
:) This is sometimes the case, in other situations there can be a lot of CPU time lost to the JIT, because code is just executed once or twice.
The weird part is: the JIT's we know today don't store their compiled code. Why not? Ok, some optimalisations are part of the executionpath the program takes based on the actions and reactions of the user, but a lot of stuff is not.
Interpreted languages have the disadvantage that the result of the interpretation is lost. A JIT solves that (partly). The old discussion about whether a true native compiler can generate code that is faster than the code interpreted and compiled on the fly with a JIT, is a discussion that's not closed or won by any part. This is because there is no scientific evidence that proves any side is right (yet).
What we KNOW today is that a native compiler can generate code that is, generally speaking, fast on the target CPU. Faster than the interpreted version. We also know that the compilers of TODAY can't always predict what's the most fastest code to emit. the optimalisation schemes are very clever but not clever enough. We know that some optimalisations can only be done at run time when there is knowledge what to avoid and what CAN be optimized.
It's thus a mixture of both. However, as I said before, the addition of a JIT to a native compiled codepart, as can be done in a CPU, also adds CPU time. It's thus up to the JIT developer to keep the time added by the JIT lower than the gained speed
Besides the technical aspect: what's really important? if you want platform independance (hardware wise for example), what are you willing to pay for that issue? speed in execution? a high price in software?
If speed is the most important thing, emulation and JITs are TODAY not an option. Perhaps tomorrow or next year, when there is more information available about what is faster in certain situations: a CPU with a JIT, or a JIT with interpreted code or just a fast CPU with native code.
Take a newbie and get him started on D3D. Take another newbie and have him use OpenGL. Who will have working code sooner? :) You see: perhaps the learning curve of d3d is steeper than OpenGL's, but in the end if you want to program a full application and you need all the API's power to achieve good quality, it takes the same amount of time and effort to get there.
:). I think that the understanding these things are important is part of the learning process of both api's. The api's both provide different solutions to achieve the same goal, but the goal first has to be determined by the programmer. newbies never get that :)
the OpenGL newbie will definitely have a rotating polygon sooner. But that's not the point I was refering to
Once you need to start worrying about Visible Surface Determination, the API isn't the bottleneck: Your culling / occlusion algorithms are, along with state minimization, and texture management. Wouldn't you agree?
I agree. It's however funny to see people first don't understand statechanges are expensive and visual face determination IS important
For the most part it is. I'm curious, what part of OpenGL isn't orthogonal? For me: display lists: it's a whole bunch of hoopla but no speed increase nowadays, and the global orientation of the code: it's nice to have everything global, but it can also work against you, especially in a OOP environment IMHO.
MS shoved D3D down our game developer throats whether we wanted it or not. OpenGL works for games, as Carmack has shown us. They already had OpenGL on NT, why did they have to go and FIX ANOTHER API?
There were numerous api's. Not one was 'major', perhaps Glide was. MS created DX (not only D3D) to provide a uniform layer of abstract code using COM, which was always the same, independant of the underlying hardware. It solved a problem for gameprogrammers: which api would we take? Glide? MeTal? OpenGL? Not one of these was supported by ALL cards. D3D is. For gameprogrammers this was a blessing because they could now focus on 1 API.
The D3D drivers are very small, because the HW vendor just has to implement the very basic stuff to communicate with the hardware. The rest is already implemented in the HAL. That's why it's easy to provide a good d3d driver, the opengl icd has to contain that HAL AND the HEL and the driver.
Question: How does a vendor provide extensions in D3D ? Oh wait, they CAN'T, unless they pesister MS to provide it in a future D3D version.
Afaik, Dx7 also contains an extension mechanism.
Nice job on DemoGL.
Thanks!
OpenGL is WAY easier to use then D3D.
:)
... because of some "politics" 3D accelerated graphics card vendors are prefering iplementing DirectX acceleration Thats because Microsoft IS so bull-headed after buying Direct3D from Rendermorphics :) Man, do you really believe this is the issue? If you know how d3d drivers are developped, you'd know that a vendor can create a d3d driver for his card with a very small piece of code. So a vendor can easily create D3D drivers for his card, which means there are _always_ d3d drivers for a certain piece of hardware. An OpenGL ICD on the other hand takes a lot more time, because the vendor has to write the complete renderpipeline in the ICD. Ok, they get a basic framework from SGI, but still.. it's a lot more work. In the past, vendors just didn't release any ICD because it would cost too much (S3 comes to mind), but today thankfully any decent cardmaker releases an ICD. It's however a shame not all of those cardmakers include all the new HW features in the ICD via extensions as nVidia does. :(
This is of course very dependant on your skills in the area of the API. If you don't get Binary Objects, if you don't understand OO, you'll NEVER understand D3D. It will be very hard then. OpenGL is a difficult API to master as D3D is too. Everyone can cook up a spinning cube, not everyone can cook up a 10.000 poly world running at decent framespeeds with a lot of different textures.
OpenGL is orthogonal. SGI had tons of experience with IrisGL before they cleaned it up and "re-named" it OpenGL.
Well, there are still some IrisGL leftovers in the OpenGL that should have been removed already. Some things are odd in OpenGL, I wouldn't call it orthogonal
OpenGL has a consistent design (look at Direct3D having 7 versions in 5 year!) OpenGL has gone thru 2 iterations in 10 years. Does that mean OpenGL has been slow to change? No, as vendors are allowed to add any extenstion they wish.
Sorry to interrupt your dreams, but OpenGL seriously is moving forward WAY too slow. I mean by this that the 1.2 specs are great but they are great for a long time already. It's now official and finally we begin to see 1.2 compliant subsystems, but it took way too long, so currently a lot of subsystems don't support any nice features which are provided by the hardware. If the standard would have forced the functionality earlier, Matrox and S3 would have been forced to implement more functionality than they did today. NO Matrox OpenGL driver NOR S3 OpenGL driver supports ANY features which make these cards outstanding: the Matrox bumpmapping in the Gxxx series and the S3 texturecompression. Sure, extensions have an advantage: vendors don't have to wait for the library supplier to release an updated version, but it also doesn't force vendors to add the features.
D3D is a young api. OpenGL is based on IrisGL. Every new technology has it's problems when it's created. IrisGL had these too. D3D is up to par now. It's however IMHO not correct to say: D3D is crap because they had a lot of version in a short time. That's BECAUSE it's new.
OpenGL also has a conformance test, guaranteeing that all OpenGL implementations are feature complete, unlike D3D. Does that guarantee speed? No. Drivers are allowed to "fall-back" into software.
Feature complete is somehow a bit stupid here. 'Feature complete' refers to the 1.1 or 1.2 featureset. 1.2 is too new to be very common, and 1.1 is very old. To be 1.1 compatible doesn't say a thing nowadays. For example ARB_multitexturing, a MUST HAVE feature today, isn't in the 1.1 set. The software fall back is a thing that annoys me the most on OpenGL. When I do a glEnable(GL_POLYGON_SMOOTH); on a GeForce card, it falls COMPLETE to software, because it can't do a part of the pipeline in software, but in D3d only parts of the not by hardware supported features, are done in software. That's IMHO a better approach.
I can only laugh about this.
Take care...
DemoGL main developer. DemoGL is a win32/OpenGL multimedia library.
Don't we?
:)
/. all day ;)). The rest of you is making his judgement on the quality of AD on what's written in the press, and especially on sites with doubtable reputations like ZDnet.
The 'MS' camp can't be, so it SHOULD be Novell. As a microsoftie (yeah flame me, I don't care) I laugh about the 'case studies' MS puts up to proof another product is bad/wrong/whatever. Whoever goes for that crap is truely in the wrong profession. Same goes for the other company's marketing departments and their mudthrowing 'Case Studies' about the products of the competition. You fall for those too?
I hope not
For the people who already know what's right and what's wrong: beware what you believe. Think who spread the texts you think is right. Is it the company or is it the techteam working on the product?
About the NDS vs AD debate. NDS is already out there for some time now. It wasn't up to par when it saw it's first light, it seems to be usable very well in lots of environments. So people get used to it, know it's strengths etc. AD on the otherhand isn't even out there. It's not even released. No-ONE has seen it. Only selected testers who got RC3 (and I don't think a lot of them are reading
Novell fights for every percent marketshare they can get. It's their right. For people who have to use products from both companies, MS or Novell, it's better to test out what's there, and judge for ourselves.
And that is only possible AFTER Feb. 17.
Or did you all do excessive tests with AD on a serverfarm full with win2K server machines and numerous clients and also the same test with NDS?
I guess so...
I'm an MSCE too (9 certificates) and I think the domain model is great. DNS is a static system, which should be removed a long time ago. These 2 things are not related really. The domain system used in NT is not usable on the internet and vice versa.
:). NDS is ok, you say it's FAR superior to AD. Ok, let's have it then. throw it out in the open and explain WHY it's so incredibly far more superior.
Because you hate it and I love it, makes it even I think. Your opinion is biased by your personal favor. That's totally ok, but not usable in a discussion.
About kerberos, you're correct. It was a dumb phrase of me to call it encryption. It's a system to secure authentication like lanmananger protocl is, ok. I ment that, I used 'encryption', which is of course not the case. It's however a step in the good direction to let go the lanmanager protocol and choose something that is already implemented and has proven to be ok (at least to be better than what's there today in NT ;). Implementing it with bad code is of course the nail on the coffin of a secure NT system. What I ment to say with my zillion lines is that IMHO MS has learned from the past (so history IS important but not in a way to prove the future will be bad as well) and will commit itself to a more secure environment so the weak spots are not due to weak software as demon also pointed out and we all know was true for a few years in NT land. The topic is/was if MS will commit itself to a secure OS, and I say, looking at what they've put into their new OS plus what they've done to make NT 4 secure... yes, they will.
:)
But time will tell. IMHO they've tried hard enough. Open source IMHO wouldnt have made it any better, because a lot more developers have looked at the code outside MS (for example a lot of developers at IBM have), than before. Ah well...
I'm a programmer, worked on both unix and NT for years, not administrated them (well NT I did, only admin on AIX a few years back). I won't say history is meaningless, every day we learn it is not meaningless, but in productcycles, you can't predict the quality of a future product, looking JUST at a history record or lists of bugs in the early days. :). If the software is flawed, it's of course undoable to make it work 100%. IMHO if you throw up as many steep hills as possible, it's almost undoable for a hacker to break in. It must become uninteresting for a hacker to go on. I think then you can cover the last bit of percent all systems indeed lack in total security. I'm glad MS finally is aware that the market is not waiting for lots of NEW stuff, but actually WORKING stuff. Which also means the tools to make it secure. (so it's the admin's fault that there is a hack).
Only time will tell if they are right. no history can IMHO.
Long posting... Main line of my posting: nothing is secure, you have to make it secure yourself. So that means, I'm not saying NT is more secure than anyting else or anything else is more secure than NT. (offtopic discussion, btw.).
Few things: about the security fixes... the few security leaks in NT in 1999 were patched within a day or 2 and downloadable for everybody. And about the history.... my point was: the history of NT when it was first released and with the bad servicepacks 2 and 4, is not necessary true for the future. You USE that history to make it look bad, while from your text I can IMHO conclude you don't have a lot of experience with administrating NT server. That's not bad, but calling it bad, plus it's security bad, BECAUSE history tells you so, is IMHO a bit shortsighted. It doesn't matter which OS, if the admin is sloppy, the system is insecure.
tell me, why would I believe you, that MS told a lie, and not MS? because they are liers, right? I've been reading and posting to that guestbook on www.windows2000test.com every day during the test. They had found some severe leaks in the tcp stack, some crappy bugs in the script, some DoS results, but after a month... all were gone... no attack gave any result. Ok, you obviously won't believe the statistics they posted every day about the amount of DoS packets or hack attemts the server received, but it was an awefull lot. They were very informative when the server was down or when they found a bug or when the server was crashed (it crashed a couple of times in the debugger). Also think about the fact that no firewall was there, every spoof package was passed through. Sure, any unix server which was setup by a security professional, would have survived it too, but just because there weren't any security leaks reported, as people breaking into the server, doesn't have to mean MS is lying.
After all, it was a technical test. They do that too, you know.
G: Well, you have to have exp... You know, if somebody's camouflaged the thing pretty well... That's a question of fact, not of law. The question is, did they borrow from my work, okay? [...]
Interesting subject, because... what if you port GPL code to another programming language, or better, you snip out a part of the code and recode it because you use the idea behind the code, in your own code. Borrowing, or theft and THUS voilation of copyright law because voilation of the GPL... any thoughts?
NT's security is NOTHING like you'll find on linux or any other unix or similar. Whohoa. On what kind of fact is this based?? On the fact Unix's security is based on 1 superuser which is needed for all daemons? on userrights instead of object rights?
To me it sounds like people who rate NT's security as 'lame and nowhere the level of security on Unix is' really don't have a clue about how NT's security works.
Let me sum up a small list of items, related to the topic. This is not ment for a flamebate, but to let unixpeople learn it's not windows 9x we're talking about, but NT/windows2000.
- NT is in the US/Canada area already 128bit for years. Windows 2000 will be using 128bit security worldwide.
- NT 3.x and 4.x uses the weak NTLM protocol. It could be tough to break but in areas outside US/Canada, the encryptionkey was too short to hold long. Windows2000 will use Kerberos strong encryption, which is an industry standard. Poking at MS that their encryption is weak (especially in their upcoming product) is without ground, because Kerberos is a proven secure technology.
- NT uses security throughout the system on objects. It's then way more flexible to set security flags, without the necessity to open up the system because a certain daemon needs root access, for example.
- MS fixes security leaks within 24 hours most of the time. Arguing it takes ages to get a fix are therefor unfounded.
- In the past year, there were some minor security glitches in NT itself. The security bugs in IIS are due to leaks in modules that IIS uses, not IIS itself, like the idq.dll module for old style indexserver queries. Today you don't need these modules. Still, unskilled administrators install the basic set. Like unskilled administrators will with RedHat 6.x on their hands. That's why there are idiotproof docs to guide these (majority, unfortunately) people.
:) - IE holes are a problem, but who surfs the net on a production server.
- MS provides a bulkload of security documents how to implement security on your servers. These are perhaps silly for die hard techies ("Duh! don't install the examples!!"), but MOST of the system administrators, ALSO on unix, are not people with 10 to 12 years of experience with administrating servers. Don't forget that. Most sites which are hacked are setup by not well skilled people. Pointing at the OS is silly. No-one says unix is unsave because sendmail is crap. the administrator should be aware that the sendmail on his system is likely an older version than available today.
- Which brings the last and most important subject to the surface: if you don't follow the security sites, if you don't apply patches REGULARLY!, if you don't know what to close and what to remove from the system to keep/make it secure, and most important: if you DON'T let a 3rd party, specialized in security, scan your systems for leaks, your system won't BE secure, no matter what kind of OS you have. Admitted: some OS-es have LESS open doors than others, but NO OS has NONE closed doors. Don't forget that.
NT 4 was a wise lesson for MS. They have it on track now, but it has been a long road. It's nowhere near the end, there are still areas for improvement, but these are there too in other OS-es, like Linux or *BSD. Being aware of the weaknesses of your own system is a Good Thing (tm). You can then secure it more. Blinding yourself with talk that only MS makes insecure stuff is silly. Ask all those Solaris administrators currently suffering the DoS wormsBashing the FUTURE without knowing what it will bring (have you all used Win2K server??? have you tested the security???) with the facts of old material from the past is not fair. If you turn around the roles and people will bash Linux using the hundreds of holes in all the distributions which were found in the last 2 years and say: "linux is not secure... because of all those leaks in it in the past years." is that fair? I'm pretty sure you'll say: "No!".
You are right about we should focus on the real red line in the article, which is about a VM solution in FreeBSD. However, the fun gets spoiled by more than 20 lines of TOTAL UNNECESSARY craptalk about what's bad in this and buggy in that. Because the mudthrowing of Dillon is in his article, I can comment on that in this forum. He might have achieved a lot in this world, he still has to OR 1) pay respect to others who also have achieved a lot in this world and work also very hard and thus focus on the subject of his article and leave the mudthrowing to others OR 2) point out WHY others are bad and buggy when throwing mud.
He chose the 3rd option: throw mud and hope for the right audience who will love him for that mudthrowing. Well, some will, other won't. And that's sad.
Because what would have been REALLY interesting is: the NT model of threads attaching to loadable libraries in core and how NT solves the problem mapped on how FreeBSD solves the problem with processes, not threads, because he focussed the reader on the NT topic as being crappy because it has flaws that were solved decades ago in Unixland.
. I read you ask for respect for mr. dillon and for not being immature. Well, I can only answer: I don't respect people who throw mud at others without pointing to the reasons why. That means: you MAY throw mud on others, but explain why. If you don't, you are just the same as the people you describe, a teenage male looking for yet another venue to release their now trendy, "geek angst".
The article itself was pretty straightforward and insightful. Insightful because it let you look into the kitchen of FreeBSD without you have to crawl through lots of code. That's a Good Thing (tm). It wasn't really 'new' or '21st century tech' to me. Because IMHO a process fork() is something a modern OS shouldn't do, but instead spawn threads.
Mr Dillon knows more about FreeBSD than anyone outside Microsoft can know about NT
do these things relate? Back to the topic: if NT is packed with errors solved in Unix a decade ago, relating this to the actual topic of the article, are there designflaws in NT's VM handling? Don't come out now with the words 'we don't know! we don't have the source!!', because that's bollocks. There are numerous documents written by a lot of people about NT's internal structure and also about the VM handling and specifically connected with threads (the buildingblocks of NT's multitasking, Unix uses processes as building blocks). So, in the light of the article, what is so incredibly wrong? Mr. Dillon makes the, IMHO not so clever, remark that NT contains flaws unix doesn't have. So I say: which? because he MAKES the remark, he KNOWS what's wrong, right? otherwise how can he say THAT there is something wrong... that was my point. Perhaps offtopic, whatever, and already moderated down because it's perhaps hurting for the OS OS people here, but I just want to know.
Ah well....