What he ment was that if you compile your GPL-ed stuff together with any other piece of software, that piece of software should be opened up also: A (gpl-ed) is connected with B (closed/other license). If B is compiled with A, you HAVE TO open up B because that's what the GPL states.
So if A is motif and you're writing B, and choose another license than the GPL AND A is gpl-ed, you're out of luck: you can't decide to release B closed.
Besides that, if you release it under the GPL, you give away the (c) to the FSF. Re-read it. It's there. --
What you describe is called COM or in the stone age: OLE. reuse of building blocks of other programs in your own program. Windows programs today do that a lot. Perhaps it's new to Unix developers, but not to win32 developers.
I don't get why an end-user is involved in the equation: the end user just fires up a program to work with. He/she couldn't care less how that program will perform it's work, just that the work is DONE.
Btw: IE is a com object for years. It comes with several interfaces really, so you can just bind to the object and create your own editor with it within a few lines of code. (Homesite does that for example).
The funny thing you mention is 'DOS world'. that world is dead for ages, pal. Also: the world isn't about colliding zillion tiny programs on a command line with pipes, but dynamic loading and linking to binary libs, loading and linking to binary objects. THAT's the real deal. And unix is still far far away from that. --
But... did the Linux community pick it up? Not at all....
Very weird. It's open since last year, so you all should have had some time to port it to Linux. After all, it's userinterface is in delphi but the rest is written in python.
I'm from The Netherlands, Europe and I simply can't understand why a country which thinks is the best on earth (USA) lets this to happen:
1) A second trial on the SAME matter as a previous trial (namely IE integration in windows) is held by the SAME judge as that previous trial. The previous trial is overruled in higher courts, making the judge of this trial loosing his own verdict... -> personal anger and ground for bias. 2) Just 1 single person will decide what to do with a 500BILLION$ company, a company that produces products which make numerous other companies live and make money, a sum far far larger than what most countries on earth are spending each year. Oddly, this judge has lost the same trial to a supreme court already earlier on. A biased, single person will now decide how this all will end.
Personally, if you don't understand WTF this trial is all about, just reading the 2 points above makes you wonder why just 1 single person is able to judge about this company PLUS why is this SAME judge doing this trial and not another judge (because of possible bias). The judge is biased, or CAN be biased, because of previous experiences with the company involved.
Judges are also humans and not machines. True, a true true professional won't be having hard feelings about a previous lost trial, but this is very rare to happen. My parents in law are both a judge here in The Netherlands and they said to me it's totally not possible to exclude even the slighest bit of personal opinion in verdicts, no matter how hard you try....
At least 3 judges on this massive case would have been reasonable. It's not Johnny's Cookiestore, which is at stake here. (Sorry, anti-M$ fanatics: real life facts are real life facts, the money in your pocket could be at stake too, even if you think you earn every dime with just NON-MS products. Think about it) --
They just extended the protocol. Extensions is adding additional functionality while keeping the rest in tact. That's what they did. Period.
The fuzz is not about the MS implementation of the protocol part. It's about the extension part. While there is NO SPECIFICATION WHATSOEVER in the protocol specs that states that extensions should be open too, people here think MS HAS TO open up the extensionimplementation. of course they don't have to.
The Mac implementation is just an implementation of the protocol. If Apple adds an extension to the protocol, using own developmentresults, why should that be a voilation of MS' proprietry? Only if Apple copied MS' extension specifications AND says it's Apple's property. Like Mercedes rips of Ford's secret enginedevelopment's secrets and says it's theirs. Yes this is the same thing.
Now, all: stop whining like a spoiled kid and get to work. There is a kernel to release. --
o dear. well.. for your information, some people on earth DON'T have english as their native language. and I can assure you I speak better English than you speak Dutch:) The 152 is official tested. Not that I care. An IQ test doesn't proof anything about a person's intellect. I'm not good in languages for example (ok, programming languages are ok;)
You explained in a most clear way WHY most 'advocates' just kill the product they evangelize. A good advocate should convince people with cold hard facts, theory and reason. Not with insults. The insults from most Linux 'advocates' (I call them zealots) made me whipe linux off every harddisk here in the company. I don't want to be called a 'Linux User' when the average IT-Joe understands that a 'Linux User' is a bigmouth-lowIQ.
Thankfully there are also a lot of reasonable people among Linux users. I truely hope for them the bigmouths will quiet down.
to understand HOW the 'community' reacted. The other main story about the 'drop' of opengl support (and thus mac/linux) here on/. is a total cry for -1, troll. Most people simply think a gameengine IS the api (huh?) but most of the code is simply not api-oriented. If they don't port it, some linux-game oriented company can pick up the small part of d3d specific code and port it to opengl. Big deal.
And besides that... how many people BUY games when they're available for linux? BUYING software isn't in the linux user's mind (because everything is free and open).
Does any of you know how a 3D engine works? only the backend renderer needs to call the 3d api to visualize stuff. the rest is just internal database management, gamecode, I/O etc. No d3d specific code. That the engine he's producing now is D3D only is not a weird thing: it's portable easier to the X-box, plus you can truely write an OO engine.
Porting the engine to other platforms takes time but not that much. If there will be a huge market for linux games (which there isn't, so why putting any money in a linux game) they will add an OpenGL renderer. They need to add a psx2 renderer anyway. Because OpenGL is now beeing ported to the psx2, OpenGL support is only a matter of time. (But sweeney doesn't like OpenGL, and face it: it's not a statement he made public himself, it's a note from the E3 from a reporter who probably heard this in the mensroom where sweeney and carmack both were taking a dump and calling eachother names)
Here in The Netherlands we have a copyright law that states that if you create something it's yours, you have the copyright on that material. It doesn't matter if I release that material under a license, say GPL. I still have that copyright. I can only transfer copyright by a written contract by a notary. Because I don't do that when I release my source under a GPL, no-one but me has the copyright on MY source. And correct me if I'm wrong, but most western countries have such copyright laws.
I also think that distributing the copyright and releasing it under the GPL for keeping it as sourcecode are 2 different things. Perhaps some people feel the urge to distribute the copyright of their material to the FSF, but I personally can't see any reason for that: it doesn't matter if you do that or not if you use the GPL for your sourcecode. It only has affect on your rights on the sourcecode YOU wrote if you want to take it OUT of the community and do something else with it. Distributing the copyright to other people makes you unable to do that. (No, that's not evil, think! you can come up with some situations wherein this can be useful).
Freedom, that is not equal to signing away your own property to others. --
I don't get it?:) What is it I don't understand? Linux wants to be an NT domainserver? why? I mean, NT's structure is totally different than Linux' structure: the security model, the internal behaviour focussed on security, networking and security etc. Linux and other unices should be used as unix systems the way it's designed: a central computer where everybody works on. NT is not based on that idea. It's focussed on a set of servers where everybody works on. That's different. You can't force one into the workingmethod of the other. Period.
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. For both operating systems there is place in the market, for both OS-es there are people who think it's the right choice for their situation: OR central focussed computing OR distributed computing.
The problem with you and your fellow advocates is: you don't understand the people you're talking to. I mean: I worked for years with Unix, I've a linux system here today. I understand what's all about, but I also understand what's all about in win32 land. There you go wrong. Now I'm a toady it seems. The attitude you show is AND lacking knowledge how real life IT works AND lacking knowledge about other systems in the world AND lacking respect for other people. This attitude also says to me I never HOPE to be called a Linux User if the loud mouth zealots keep their attitude. Have a nice day. --
:) 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. Bull. As said: you don't need hidden api crap to operate ok. Novell can do it, they provide an own client. This is the right way to do it. you refer to mixed environments with BSD and Linux and win32 clients? Well, how do those win32 log in to those UNIX networks and carry their security token with them to other servers like Linux powered Samba servers? If Linux would be equipped with a client for win32 (like the client for netware) it would be ok. But that's the other way around. However it's not microsoft's problem when there's no client for win32 that supports a serverside OS.
I'm not a microsoft employee, I own my own business. I ment Clib (as in C's standard library;) (or was it libc?)) to illustrate Linux has it's own problems with API's:)
hahaha and stop telling me what's gnu's all about. Back in university I already refused to use gnu tools and used Sun's own. I'm a convinced Microsoftie and true Linux advocates like you make me realize every day I made the right decision:)
I'm not babbling here to try to convince you you're on the wrong platform. There is no such thing as being on the wrong platform. I just try to enlighten people who are misinformed or don't have all the info at hand to make the right decision. 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.
I used the word 'whine' in the context of 'general speak', not to target at you personally nor your texts. You asked for a clue, I tried to enlighten you with a bit of information why the windows platform is organised the way it is organised and how it should be used. The 'whine' comment was there to state that the arguments about win32 and the 'mistery of the hidden api's' are plain whining. With win32 you can build what you want, use it, be productive.
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.
Huusker just wants to use functions in the layers below win32, because he thinks it's better. Well it's not. Win32 is designed to make the layers underneath a black box. If there is functionality in layers below win32 and win32 doesn't provide this functionality it's OR because the functionality is there for layers below win32 OR it's a designflaw. Because win32 is not a new api, and revisions/updates are done regularly, a designflaw (especially undocumented flaws!) are very rare.
But I'll take my win32 elsewhere, you asked for information but you can't stand the answer. So all I can do is wishing you good luck with clib:) --
John Wiltshire, without a doubt. Huusker doesn't understand how win32 development works, or how microkernel systems work. MS made the win32 api for just 1 purpose: developers could just use 1 api and it will always work, no matter what MS would do underneath in the kernel layers on top of the microkernel. Therefor functions in the layers below win32 are sometimes not documented, for the one and only reason that people should use win32 equivalents. (like Huusker should look at the Platform SDK/Security tree in the MSDN. If you still need extra functions from layers below win32, you definitely don't understand the big scala of functions provided by win32)
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. (Good example: there is not a function in win32 that gives you a list with all the files in a directory. You have to use 3 functions from the win32 and some lines of code to create this list yourself. Some people believe that there IS such a function somewhere in the huge pile of functionality inside win32.(below it, in lower OS layers)).
The main reason why John Wiltshire is right is because there is just one reason why an OS succeeds and for MS thus makes a lot of money: when there is software for it that works and LOTS of it. When people are NOT able to create software because they just CAN'T write working code because they lack serious information, the amount of software is declining and the success of the OS will vanish. Therefor Microsoft has put up the largest base of developer information on the net: MSDN. But you know what? still people try to find ways to whine about that large pile of information. Like mr Huusker. You don't need subsystems to emulate a fork(). This is because NT is not PROCESS oriented but THREAD oriented. trying to write UNIX like software on NT is only possible if you PORT parts of UNIX SPECIFIC code to NT specific code (which only should be small parts of the system). I mean, an NT Thread definitely isn't waiting of there is a SIGV_KILL coming along.:) --
Who needs MySQL for performance?
on
Why Not MySQL?
·
· Score: 2
http://www.tpc.org/new_result/ttperf.idc
WHy isn't MySQL in this list? because it doesn't have transactions. Transactions are the most vital part of a database system that is used in critical environments. Why? because you ABSOLUTELY have to be sure some action is completed correctly OR if there was a failure, has rolled back to its initial state before the (serie of) transactions were executed.
O, and the database system on top of the performance list is a beta.:) --
When you develop software by first designing it on paper with Functional Design and Technical Design reports, make database diagrams, N-Tier schema's where to put which functionality and code, UML schema's for your classes, you only have to type in what's already thought out. The only flaws you'll experience is bad algorithm coding (but that's not spagetti code) or detailbugs.
When you develop software using the evolutional model, that is: add code/functionality on the fly in an ongoing basis with short term designs and not based on original concepts and designs, you end up with eventually (most likely) a pile of code that has to be rewritten NOW because a new feature asks for it. because most of the time in these projects people do NOT choose to rewrite it, it's added anyway, resulting in spagetti.
In Short: evolutional model code is code where no theoretical basis is stated, there is no original manifest that illustrates WHY all the code is set up like this. MOST OSS projects are developped using the evolutional model. What helps is an ONGOING theoretical design document to function as a theoretical BASIS for the structure of the code. If there is NO designdocument or conceptdocument stating WHY code is structured the way it is structured, it's bad code. Period.
Another thing that adds up to bad coding is a bad naming scheme, or worse: no naming scheme at all! Nobody is forced to use hungarian coding, but please CHOOSE one! develop your own if no scheme suits you, but a scheme that HAS TO BE used by all developers in a project is a MUST to keep the code clean and updatable, even if you use designdocuments.
More and more OSS projects get tighter software teams with people who KNOW how to develop software, thus using designs and theory before starting to jam in the code, and that is a good thing. We ain't there yet however. For starters I'd suggest to take a look at the InfoZip sourcecode: ansi and non-ansi C together in 1 project... *UUHHHHH* --
Erm, forgive me if I'm wrong, but afaik, if ONE snippet of code you use in your system is GPL-ed, your code should also be GPL-ed, because you are not allowed to link to GPL-ed code from closed source software.
If this is true, BeOS should be totally GPL-ed as well. Can anyone enlighten this a bit? (I'm sure someone can;) --
I'm also aware of the fact that not all of the stuff that comes from MS is THE solution to a problem. The original poster tried to illustrate the fact that people should NOT idealize to the max the technology that is their favorite. Instead, people should keep their eyes OPEN to what is best for the particular problem. This means, besides everybody's favorite piece of software, try to truely convince yourself WHY you would choose for product X if a certain solution is needed.
Sometimes I advice my clients to pick a Unix based solution, sometimes I don't. MS' COM based technology today is my favorite development technology to build with. That doesn't mean I don't look at Linux, *BSD or Solaris.
And that's the point: too much people here start to rant and rave when there is something negative to say about MS, even if it's very small. This site is one of the most hypocrite on the net when it comes to Microsoft, and that's a true entertainmentfactor to consider so that's why I'm here:). Especially the topic about the certain DLL is funny, how it evolved here into a true devil's tool to hurt people. The reason for that is because MOST people here are too shortsighted: they consider just their favorite piece of software THE solution for EVERY problem.
Which is sometimes true, but also a lot of times not true. --
You all really don't get it, do you? the real platforms which do matter for the people who are going to DEVELOP for this OpenML platform, are THOSE platforms which are used by the MAJORITY of their potentional CONSUMERS, namely the people who are going to buy and play their games.
Ever wondered which platforms?
for starters: NOT Linux on PPC, NOT OpenBSD or MSX.
These platforms are the CONSOLES and consumer windows (win9x, winME). Write an API that works on THOSE platforms and you're set. Why? Because the gamedevelopers are developing games for the money, for selling products. They are only able to sell their products if the potentional consumers are able to use it and as a producer you only make any profits if you sell a lot.
The initiative is very ok in theory, but only if it's for the platforms where the most gamers are on. This mostly excludes Linux, no matter how much you probably hate that.
Futhermore, as some clever reasonable minds have pointed out already: an api has to mature before it's even USABLE. And if that time arrives, is it a BETTER alternative for what's available ALREADY.
If I assume this time will arive around 2002, I'm pretty sure the alternatives are unbeatable. It's sad but true. (O, and perhaps you think Linux is THE desktop OS... that's highly unlikely.) --
Visual Interdev 6 contains a dll, MDT2LV.DLL, which also contains the string. Apparantly to keep compatible with old visual interdev 1.0/old frontpage extensions websites. According to my dissassembled dvwssr.dll, it's used to crypt/decrypt the querystring passed to it by the requestobject.
Not a backdoor for sure. It's just now EASY to sniff traffic to a website, from an visual interdev 1.0 client/frontpage 1/2.0 client to a webserver with these extensions, decode the strings, then possibly get the username/password and THEN brake in.
Visual Interdev 6 uses a different scheme to communicate with the server, so it's just for old visual interdev 1.0 users (are there any left?) and old frontpage users who are vulnerable.
in the same dir as dvwssr.dll is located, there is a dll named 'author.dll'. This one is a debug version afaik. this is the text I found in that dll (I thought, let's check the others for other funny texts!):
$Header:/frontpage/server/source/rpctesti/rpctesti.cpp 18 5/28/97 10:55a Jkatzman $ Copyright (c) 1995-1997 Microsoft Corporation fprpctest Fri May 15 12:48:28 1998 Windows/NT
erm... well... doesn't look like production code to me:) Is this 'Jkatzman' name also a backdoor???? probably. --
A string backwards in a certain dll. It's suddenly a password... is it? and for what? The dll itself doesn't export any functions except HttpExtensionProc to serve IIS as an isapidll.
From MSDN:
The FrontPage Extensions manage design-time Web permissions using the underlying security model of the host operating system on the server. Here we consider only the case where this operating system is Windows NT 4.0 with the NTFS file system.
FrontPage manages administer and author access to a Web using the same technique. In the Web's root directory, FrontPage creates a directory named _vti_bin. Within this directory it creates two sub-directories, _vti_adm and _vti_aut. Within _vti_adm FrontPage places a file, admin.dll, and within _vti_aut it places two files, author.dll and dvwssr.dll. These DLLs are ISAPI extensions. During design-time, client requests arrive over HTTP at the server and are routed to one of these ISAPI DLLs. A request to perform an administrative function, for example, change permissions on a Web, is handled by that Web's admin.dll. A request to perform an authoring function, for example, open a Web, is handled by that Web's author.dll. A request to fetch the source code for an ASP file without processing, for example, to view the links in that file, is handled by that Web's dvwssr.dll.
In the request, the client provides credentials that identify the user who is logged in to the client workstation. This user must have read permission (equivalent to read and execute individual permissions) for the DLL handling the request, otherwise the request is denied. Thus FrontPage restricts who may perform a given request by controlling read permission on the directories in _vti_bin. Whenever a change is made to a Web's permissions via the Web Permissions dialog box, the FrontPage Extensions on the server modify the ACLs on the directories _vti_adm and _vti_aut in that Web's _vti_bin directory accordingly.
Note FrontPage does not change ACLs on content files to manage design-time security; it only changes ACLs on the directories that contain the gatekeeper files admin.dll, author.dll, and dvwssr.dll. FrontPage manipulates content file ACLs to manage run-time security.
So it CAN be that there is a backdoor in the DLL, if it surpasses the checks on ACL's on the files to be accessed. If you delete the DLL, you can't edit the pages ONLINE via MS Frontpage. The reason some people use Frontpage extensions is because of this. It's highly recommended to use OR the much more secure VIdev Online edit/publish functionality, or just edit offline. (duh:)).
So, deleting the file won't harm runtime behaviour, it will harm edit behaviour with MS Frontpage. Well... now that's a bummer;) --
Slashdot Mirror
that's why this line is in the about box :)
--
So if A is motif and you're writing B, and choose another license than the GPL AND A is gpl-ed, you're out of luck: you can't decide to release B closed.
Besides that, if you release it under the GPL, you give away the (c) to the FSF. Re-read it. It's there.
--
I don't get why an end-user is involved in the equation: the end user just fires up a program to work with. He/she couldn't care less how that program will perform it's work, just that the work is DONE.
Btw: IE is a com object for years. It comes with several interfaces really, so you can just bind to the object and create your own editor with it within a few lines of code. (Homesite does that for example).
The funny thing you mention is 'DOS world'. that world is dead for ages, pal. Also: the world isn't about colliding zillion tiny programs on a command line with pipes, but dynamic loading and linking to binary libs, loading and linking to binary objects. THAT's the real deal. And unix is still far far away from that.
--
But... did the Linux community pick it up? Not at all....
Very weird. It's open since last year, so you all should have had some time to port it to Linux. After all, it's userinterface is in delphi but the rest is written in python.
Get it: http://www.planetquake.com/quark.
--
1) A second trial on the SAME matter as a previous trial (namely IE integration in windows) is held by the SAME judge as that previous trial. The previous trial is overruled in higher courts, making the judge of this trial loosing his own verdict... -> personal anger and ground for bias.
2) Just 1 single person will decide what to do with a 500BILLION$ company, a company that produces products which make numerous other companies live and make money, a sum far far larger than what most countries on earth are spending each year. Oddly, this judge has lost the same trial to a supreme court already earlier on. A biased, single person will now decide how this all will end.
Personally, if you don't understand WTF this trial is all about, just reading the 2 points above makes you wonder why just 1 single person is able to judge about this company PLUS why is this SAME judge doing this trial and not another judge (because of possible bias). The judge is biased, or CAN be biased, because of previous experiences with the company involved.
Judges are also humans and not machines. True, a true true professional won't be having hard feelings about a previous lost trial, but this is very rare to happen. My parents in law are both a judge here in The Netherlands and they said to me it's totally not possible to exclude even the slighest bit of personal opinion in verdicts, no matter how hard you try....
At least 3 judges on this massive case would have been reasonable. It's not Johnny's Cookiestore, which is at stake here. (Sorry, anti-M$ fanatics: real life facts are real life facts, the money in your pocket could be at stake too, even if you think you earn every dime with just NON-MS products. Think about it)
--
They just extended the protocol. Extensions is adding additional functionality while keeping the rest in tact. That's what they did. Period.
The fuzz is not about the MS implementation of the protocol part. It's about the extension part. While there is NO SPECIFICATION WHATSOEVER in the protocol specs that states that extensions should be open too, people here think MS HAS TO open up the extensionimplementation. of course they don't have to.
The Mac implementation is just an implementation of the protocol. If Apple adds an extension to the protocol, using own developmentresults, why should that be a voilation of MS' proprietry? Only if Apple copied MS' extension specifications AND says it's Apple's property. Like Mercedes rips of Ford's secret enginedevelopment's secrets and says it's theirs. Yes this is the same thing.
Now, all: stop whining like a spoiled kid and get to work. There is a kernel to release.
--
Please forgive me if I'm wrong but didn't corel need inprise for the cashflow? isn't corel heading bankrupcy now because the merger is off?
--
Happy now, yankeeboy?
--
You explained in a most clear way WHY most 'advocates' just kill the product they evangelize. A good advocate should convince people with cold hard facts, theory and reason. Not with insults. The insults from most Linux 'advocates' (I call them zealots) made me whipe linux off every harddisk here in the company. I don't want to be called a 'Linux User' when the average IT-Joe understands that a 'Linux User' is a bigmouth-lowIQ.
Thankfully there are also a lot of reasonable people among Linux users. I truely hope for them the bigmouths will quiet down.
Otis, IQ:152
--
to understand HOW the 'community' reacted. The other main story about the 'drop' of opengl support (and thus mac/linux) here on /. is a total cry for -1, troll. Most people simply think a gameengine IS the api (huh?) but most of the code is simply not api-oriented. If they don't port it, some linux-game oriented company can pick up the small part of d3d specific code and port it to opengl. Big deal.
And besides that... how many people BUY games when they're available for linux? BUYING software isn't in the linux user's mind (because everything is free and open).
--
Does any of you know how a 3D engine works? only the backend renderer needs to call the 3d api to visualize stuff. the rest is just internal database management, gamecode, I/O etc. No d3d specific code. That the engine he's producing now is D3D only is not a weird thing: it's portable easier to the X-box, plus you can truely write an OO engine.
Porting the engine to other platforms takes time but not that much. If there will be a huge market for linux games (which there isn't, so why putting any money in a linux game) they will add an OpenGL renderer. They need to add a psx2 renderer anyway. Because OpenGL is now beeing ported to the psx2, OpenGL support is only a matter of time. (But sweeney doesn't like OpenGL, and face it: it's not a statement he made public himself, it's a note from the E3 from a reporter who probably heard this in the mensroom where sweeney and carmack both were taking a dump and calling eachother names)
Get a grip...
--
Here in The Netherlands we have a copyright law that states that if you create something it's yours, you have the copyright on that material. It doesn't matter if I release that material under a license, say GPL. I still have that copyright. I can only transfer copyright by a written contract by a notary. Because I don't do that when I release my source under a GPL, no-one but me has the copyright on MY source. And correct me if I'm wrong, but most western countries have such copyright laws.
I also think that distributing the copyright and releasing it under the GPL for keeping it as sourcecode are 2 different things. Perhaps some people feel the urge to distribute the copyright of their material to the FSF, but I personally can't see any reason for that: it doesn't matter if you do that or not if you use the GPL for your sourcecode. It only has affect on your rights on the sourcecode YOU wrote if you want to take it OUT of the community and do something else with it. Distributing the copyright to other people makes you unable to do that. (No, that's not evil, think! you can come up with some situations wherein this can be useful).
Freedom, that is not equal to signing away your own property to others.
--
I don't get it? :) What is it I don't understand? Linux wants to be an NT domainserver? why? I mean, NT's structure is totally different than Linux' structure: the security model, the internal behaviour focussed on security, networking and security etc. Linux and other unices should be used as unix systems the way it's designed: a central computer where everybody works on. NT is not based on that idea. It's focussed on a set of servers where everybody works on. That's different. You can't force one into the workingmethod of the other. Period.
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. For both operating systems there is place in the market, for both OS-es there are people who think it's the right choice for their situation: OR central focussed computing OR distributed computing.
The problem with you and your fellow advocates is: you don't understand the people you're talking to. I mean: I worked for years with Unix, I've a linux system here today. I understand what's all about, but I also understand what's all about in win32 land. There you go wrong. Now I'm a toady it seems. The attitude you show is AND lacking knowledge how real life IT works AND lacking knowledge about other systems in the world AND lacking respect for other people. This attitude also says to me I never HOPE to be called a Linux User if the loud mouth zealots keep their attitude. Have a nice day.
--
O boy.
:) 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.
;) (or was it libc?)) to illustrate Linux has it's own problems with API's :)
:)
;) hahhaha :) that really made my day.
Bull. As said: you don't need hidden api crap to operate ok. Novell can do it, they provide an own client. This is the right way to do it. you refer to mixed environments with BSD and Linux and win32 clients? Well, how do those win32 log in to those UNIX networks and carry their security token with them to other servers like Linux powered Samba servers? If Linux would be equipped with a client for win32 (like the client for netware) it would be ok. But that's the other way around. However it's not microsoft's problem when there's no client for win32 that supports a serverside OS.
I'm not a microsoft employee, I own my own business. I ment Clib (as in C's standard library
hahaha and stop telling me what's gnu's all about. Back in university I already refused to use gnu tools and used Sun's own. I'm a convinced Microsoftie and true Linux advocates like you make me realize every day I made the right decision
I'm not babbling here to try to convince you you're on the wrong platform. There is no such thing as being on the wrong platform. I just try to enlighten people who are misinformed or don't have all the info at hand to make the right decision. You apparantly are not well informed and believe that if a person just knows something about win32 he's a microsoft employee
Frans Bouma, BsC.
--
I used the word 'whine' in the context of 'general speak', not to target at you personally nor your texts. You asked for a clue, I tried to enlighten you with a bit of information why the windows platform is organised the way it is organised and how it should be used. The 'whine' comment was there to state that the arguments about win32 and the 'mistery of the hidden api's' are plain whining. With win32 you can build what you want, use it, be productive.
:)
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.
Huusker just wants to use functions in the layers below win32, because he thinks it's better. Well it's not. Win32 is designed to make the layers underneath a black box. If there is functionality in layers below win32 and win32 doesn't provide this functionality it's OR because the functionality is there for layers below win32 OR it's a designflaw. Because win32 is not a new api, and revisions/updates are done regularly, a designflaw (especially undocumented flaws!) are very rare.
But I'll take my win32 elsewhere, you asked for information but you can't stand the answer. So all I can do is wishing you good luck with clib
--
John Wiltshire, without a doubt. Huusker doesn't understand how win32 development works, or how microkernel systems work. MS made the win32 api for just 1 purpose: developers could just use 1 api and it will always work, no matter what MS would do underneath in the kernel layers on top of the microkernel. Therefor functions in the layers below win32 are sometimes not documented, for the one and only reason that people should use win32 equivalents. (like Huusker should look at the Platform SDK/Security tree in the MSDN. If you still need extra functions from layers below win32, you definitely don't understand the big scala of functions provided by win32)
:)
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. (Good example: there is not a function in win32 that gives you a list with all the files in a directory. You have to use 3 functions from the win32 and some lines of code to create this list yourself. Some people believe that there IS such a function somewhere in the huge pile of functionality inside win32.(below it, in lower OS layers)).
The main reason why John Wiltshire is right is because there is just one reason why an OS succeeds and for MS thus makes a lot of money: when there is software for it that works and LOTS of it. When people are NOT able to create software because they just CAN'T write working code because they lack serious information, the amount of software is declining and the success of the OS will vanish. Therefor Microsoft has put up the largest base of developer information on the net: MSDN. But you know what? still people try to find ways to whine about that large pile of information. Like mr Huusker. You don't need subsystems to emulate a fork(). This is because NT is not PROCESS oriented but THREAD oriented. trying to write UNIX like software on NT is only possible if you PORT parts of UNIX SPECIFIC code to NT specific code (which only should be small parts of the system). I mean, an NT Thread definitely isn't waiting of there is a SIGV_KILL coming along.
--
http://www.tpc.org/new_result/ttperf.idc
:)
WHy isn't MySQL in this list? because it doesn't have transactions. Transactions are the most vital part of a database system that is used in critical environments. Why? because you ABSOLUTELY have to be sure some action is completed correctly OR if there was a failure, has rolled back to its initial state before the (serie of) transactions were executed.
O, and the database system on top of the performance list is a beta.
--
When you develop software by first designing it on paper with Functional Design and Technical Design reports, make database diagrams, N-Tier schema's where to put which functionality and code, UML schema's for your classes, you only have to type in what's already thought out. The only flaws you'll experience is bad algorithm coding (but that's not spagetti code) or detailbugs.
When you develop software using the evolutional model, that is: add code/functionality on the fly in an ongoing basis with short term designs and not based on original concepts and designs, you end up with eventually (most likely) a pile of code that has to be rewritten NOW because a new feature asks for it. because most of the time in these projects people do NOT choose to rewrite it, it's added anyway, resulting in spagetti.
In Short: evolutional model code is code where no theoretical basis is stated, there is no original manifest that illustrates WHY all the code is set up like this. MOST OSS projects are developped using the evolutional model. What helps is an ONGOING theoretical design document to function as a theoretical BASIS for the structure of the code. If there is NO designdocument or conceptdocument stating WHY code is structured the way it is structured, it's bad code. Period.
Another thing that adds up to bad coding is a bad naming scheme, or worse: no naming scheme at all! Nobody is forced to use hungarian coding, but please CHOOSE one! develop your own if no scheme suits you, but a scheme that HAS TO BE used by all developers in a project is a MUST to keep the code clean and updatable, even if you use designdocuments.
More and more OSS projects get tighter software teams with people who KNOW how to develop software, thus using designs and theory before starting to jam in the code, and that is a good thing. We ain't there yet however. For starters I'd suggest to take a look at the InfoZip sourcecode: ansi and non-ansi C together in 1 project... *UUHHHHH*
--
Erm, forgive me if I'm wrong, but afaik, if ONE snippet of code you use in your system is GPL-ed, your code should also be GPL-ed, because you are not allowed to link to GPL-ed code from closed source software.
;)
If this is true, BeOS should be totally GPL-ed as well. Can anyone enlighten this a bit? (I'm sure someone can
--
read this page on ntbugtraq.com and you'll find 2 articles about the dll. Read them, and you know what's all about.
--
I'm also aware of the fact that not all of the stuff that comes from MS is THE solution to a problem. The original poster tried to illustrate the fact that people should NOT idealize to the max the technology that is their favorite. Instead, people should keep their eyes OPEN to what is best for the particular problem. This means, besides everybody's favorite piece of software, try to truely convince yourself WHY you would choose for product X if a certain solution is needed.
:). Especially the topic about the certain DLL is funny, how it evolved here into a true devil's tool to hurt people. The reason for that is because MOST people here are too shortsighted: they consider just their favorite piece of software THE solution for EVERY problem.
Sometimes I advice my clients to pick a Unix based solution, sometimes I don't. MS' COM based technology today is my favorite development technology to build with. That doesn't mean I don't look at Linux, *BSD or Solaris.
And that's the point: too much people here start to rant and rave when there is something negative to say about MS, even if it's very small. This site is one of the most hypocrite on the net when it comes to Microsoft, and that's a true entertainmentfactor to consider so that's why I'm here
Which is sometimes true, but also a lot of times not true.
--
You all really don't get it, do you? the real platforms which do matter for the people who are going to DEVELOP for this OpenML platform, are THOSE platforms which are used by the MAJORITY of their potentional CONSUMERS, namely the people who are going to buy and play their games.
Ever wondered which platforms?
for starters: NOT Linux on PPC, NOT OpenBSD or MSX.
These platforms are the CONSOLES and consumer windows (win9x, winME). Write an API that works on THOSE platforms and you're set. Why? Because the gamedevelopers are developing games for the money, for selling products. They are only able to sell their products if the potentional consumers are able to use it and as a producer you only make any profits if you sell a lot.
The initiative is very ok in theory, but only if it's for the platforms where the most gamers are on. This mostly excludes Linux, no matter how much you probably hate that.
Futhermore, as some clever reasonable minds have pointed out already: an api has to mature before it's even USABLE. And if that time arrives, is it a BETTER alternative for what's available ALREADY.
If I assume this time will arive around 2002, I'm pretty sure the alternatives are unbeatable. It's sad but true. (O, and perhaps you think Linux is THE desktop OS... that's highly unlikely.)
--
Visual Interdev 6 contains a dll, MDT2LV.DLL, which also contains the string. Apparantly to keep compatible with old visual interdev 1.0/old frontpage extensions websites. According to my dissassembled dvwssr.dll, it's used to crypt/decrypt the querystring passed to it by the requestobject.
Not a backdoor for sure. It's just now EASY to sniff traffic to a website, from an visual interdev 1.0 client/frontpage 1/2.0 client to a webserver with these extensions, decode the strings, then possibly get the username/password and THEN brake in.
Visual Interdev 6 uses a different scheme to communicate with the server, so it's just for old visual interdev 1.0 users (are there any left?) and old frontpage users who are vulnerable.
so NOT a backdoor. stop the presses.
--
erm... well... doesn't look like production code to me
--
From MSDN: So it CAN be that there is a backdoor in the DLL, if it surpasses the checks on ACL's on the files to be accessed. If you delete the DLL, you can't edit the pages ONLINE via MS Frontpage. The reason some people use Frontpage extensions is because of this. It's highly recommended to use OR the much more secure VIdev Online edit/publish functionality, or just edit offline. (duh:)).
So, deleting the file won't harm runtime behaviour, it will harm edit behaviour with MS Frontpage. Well... now that's a bummer
--