I bet your life revolves around computers right now, doesn't it? You go to school and are saturated by computers and CS work. You go home and you're once again saturated with computers and CS homework. Hey, everyone burns out sooner or later. The key to keeping your interest in CS is to find a hobby that has nothing to do with your love for computers. Seriously.
Monotony can be mind-numbing, and can add on more than a few pounds to your already growing arse -- we call that "programmer's arse" (remember, a can of pop has 170 useless calories that go straight to your rear).
So, go out and do something. Take a break for cryin' out loud! Winter is coming shortly up here in the midwest, and I'm biting at the reigns to go cross-country skiing. In the mean time, it's rollerblades, walks, or learning how to play guitar.
I may be a geek, but I'm not a 24/7/365 keyboard-slave!
Posted by CmdrTaco himself back in
January. Has anything new been brought to the table about this? No. Come on, people. Just because news is a bit slow doesn't mean we have to resort to digging up old news.
True, but hiding from the cable company isn't that difficult. There are a number of solutions out there to make your tcp/ip stack look like that of a Windoze or Mac box. If you're using some form of NAT'ing, the cable company won't even see your network. Sure, there are some more sophisticated ways of sniffing out NAT traffic, but is the cable company REALLY going to invest time and money to bust everyone doing it? Probably not.
Besides, with the advanced routing techniques available to Linux/UNIX/BSD style boxes, you don't have to be the sole upstream provider. You can peer amongst other Wireless users that have a full/part-time connection to the Internet. Imagine redundancy over multiple users whose ISP's in turn have redundant connections over multiple networks using diverse methods of connectivity (Cable, xDSL, Modem, Leased Lines, Wireless, T1/T3, etc). Add in QOS rules to classify, route, and limit traffic. If one of you gets picked out for incorrect bandwidth useage, you're not out of the game. You may have added latency and reduction in local bandwidth resources, and your community members would have lost a fraction of their total bandwidth. Guess what, you still win; you're still connected.
Fuck with us and I will *gladly* give my life to kill you dead.
And thusly, the cycle of war continues. Strike and strike back. Notice how revenge is the only motivation necessary to continue spreading human blood. No longer is religion or culture involved, just the archaic desire for violence. I have little faith that we, as a species, ever evolve past such emotional "knee jerk" reactions.
Violence begets violence, and unfortunately, it is sometimes necessary. I fully support an organized and decisive action against the terrorists. Not for revenge or other basal needs, but for ultimate peace and order and the protection of the living.
This is why we have C and UNIX
on
MenuetOS Debuts
·
· Score: 2
I seem to recall from the "C Bible", ANSI C by K&R 2nd Ed, that C was born out of the need of improved code base maintenance. It wasn't an argument as to whether or not assembly was "better" or "faster", it was an argument as to whether assembly was a reasonably useful language for a codebase as large as an operating system. By its very nature, assembly is cryptic. Although C is a bit abstract, it's understandable at a higher level.
It's great that people wish to write applications and operating systems in assembly. They possess a greater knowledge of the hardware layer of the computer than I, and a greater need for the abstract. Given the choice, C is my preferred language. It allows me to concentrate on the application side of things, yet gives me enough low-level control that I can do hardware specific instructions w/o having to enter the assembler.
Assembly has its uses, especially in code optimization, and it will probably never go away for that same reason. It is certainly a "no nonsense" approach to programming, and ideal for embedded applications.
I don't think open sourcing such a project would be in the best interests of Progeny at this point. From what I gather, NOW was being designed as an integrated network filesystem distribution of Progeny. Think AFS with Progeny's autoinstaller, then add more remote management tools and probably a "push" style of software management. Basically, they were trying to create a Systems Administrator/Manager's wet dream. That type of project has some major commercial potential.
We know there's a difference between the term Open Source and Free Software. It is conceivable that Progeny may Open Source the software sometime in the future, but one of the reasons they are developing this internally is so they can have more control over the direction of the project. Once the software is in the Alpha stage, I bet we'll see it. Still, I wouldn't begin to guess at what type of licensing scheme they'll use. They may even surprise us and GPL it. Then again, we're talking Ian Murdock here. It may not be a surprise at all if they GPL it.;-)
Slashdotters have been claiming left and right that the very CONCEPT of proprietary software is theft, but now everybody's in a tizzy over poor Loki.
Sadly, this observation flies true to its target sometimes. Other times, you get observant people who realize that proprietary != bad. Remember, proprietary != closed-source in all cases. There seems to be a general agreement that the technical definition of Open Source does not choose sides as to whether a software product is proprietary or not. On a similar thread, Loki has demonstrated that a software company CAN work on proprietary software while contributing to GNU or the Public Domain, take SDL for example.
When finances permit, I have and will continue to support Loki Software by purchasing the fruits of their labor. Even if it is for a money-sucking Microsoft-loving company like Sierra. At least they figured out that there WAS a market in the Linux crowd. Don't confuse growing pains with utter failure, people. Loki isn't down for the count just yet!
Why is Dell halting Linux installs on their consumer desktops? Because no one bought them.
How can you compare a hardware/computer distributor to a software company? They're entirely different beasts. All of my personal dislike of Dell aside (<troll>they build shitty computers</troll>), a personal computer can easily be built for less than the average $1000 price tag Dell wants to extract from your wallets. Regardless, it's rare that any Linux install lasts very long at the receiving end of my keyboard. You think I'll trust someone else touching my machine??? <Insert control-freak explicative here>
Let's bring the conversation back to the real competition in question, software vendors. There is something to be said about supporting companies that not only support your favorite operating system, but provide positive influence to the design and gameplay of your favorite computer games.
I've said it before, and I'll say it again. Software benefits from the "many-eyes" approach to design. That's part of the reason why OSS projects are generally successful. Software company "A" hires software company "B" to port their code to another operating system. Not only does software company "B" act as a code auditor, it acts as positive and constructive feedback to the original game manufacturer. Software engineering improves, software designers skills improve, games improve, enjoyment improves.
Ah, but I've said this all before. I for one will support Loki when I can actually afford to buy another game. I've been eyeballing a few, but you know, life and its responsibilities get in the way of entertainment sometimes.
It's really hard to follow this one up with anything but an, "I agree." Perhaps this is a useless post, but to add to the show of hands and answer the question, all the music I rip from CD goes to OGG. MP3's just don't sound as good. There are sounds that you can hear in the CD recording and the OGG encording that you cannot hear in an MP3. Sorry, MP3 fans.
I am a Debian developer, but I have not involved myself with policy decisions as of yet. I can tell you my biased opinion on the subject, however. We've all heard the arguments before, why one packaging system is better than another, so I won't go into an evangelistic rant about why deb's are better. I will say that I doubt very highly that Debian will drop debs any time soon. To be compliant with LSB, Debian will continue to package rpm and alien.
That should be sufficient for allowing software vendors to feel comfortable packaging for Debian with rpm's. Of course, the use of a packaging system does not alleviate the problems with dependency resolution and binary to library incompatibilities. Vendors will still need to be careful to recompile their rpm's in the environment they expect to deploy the software. One thing that is nice about LSB is that we will know where to find the software files when they ARE installed.
1. GRANT OF RIGHTS
The rights granted under this license are limited solely to distribution and sublicensing of the Contribution(s) on, with, or for operating systems which are themselves Open Source programs. Contact The Open Group for a license allowing distribution and sublicensing of the Original Program on, with, or for operating systems which are not Open Source programs.
The definition of Open Source, as detailed in the Licenses in question is as follows.
"Open Source" programs mean software for which the source code is available without confidential or trade secret restrictions and for which the source code and object code are available for distribution without license charges.
These clauses say nothing about disallowing distribution or use on "non-free" operating systems as the original poster implied. Review definition above and compare it to the word "non-free".
Additionally, Open Group is willing to provide an alternative license for the software, as stated by the License. This caveate emptor is very similar to what Trolltech used to do with Qt. It is also a clause that keeps the Open Group API and software in the "non-free" branch of Debian. For example, this is the information on the libmotif package:
Package: libmotif
Priority: extra
Section: non-free/libs
Installed-Size: 2262
Maintainer: Gerd Knorr
Architecture: i386
Source: openmotif
Version: 2.1.30-3
Depends: libc6 (>= 2.2.1-2), xlibs (>= 4.0.1-11)
Filename: pool/non-free/o/openmotif/libmotif_2.1.30-3_i386.d eb
Size: 942620
MD5sum: 2e25a0d26da10d10a319b1b73153bbcd
Description: Open Motif - shared libraries
This package includes all files you need to run Motif
applications which are linked against Open Motif, which
are the shared libraries for the most part.
No one takes them seriously in that market yet since you can only do single CPU systems.
We can blame this on the motherboard manufacturers more so than AMD. AMD has designed a superior processor, the specs and an example chipset to run the thing. Any chipset manufacturer should be able to get the specs to design their own chipsets to work with the Athlons in single, dual, quad, whatever. The motherboard manufacturers are lazy, getting plump on their multiprocessor Intel income, or getting pressure from Intel to drag their feet -- which Intel has been known to do on more than one occassion.
It is certainly disappointing that it has taken this long for a serious attempt at retail multiprocessor boards for the Athlon to appear. Perhaps next year, when they've worked out the bugs, and when I've got a little more mula, I'll look into them.
How does that equate? Let's say you've got a Windows-centric software company that feels they've got a great product. It's well designed, fairly robust, and the gameplay is such that people will flock to buy the game for the primary target OS: Windows. The beta testers rave about it, the press is salivating.
The game releases, and as predicted it's a great success. Linux users are envious, but dislike having to dual boot their boxes. Emulation is not quite there for this new game, as it uses a bunch of Windows-centric, bleeding-edge DirectX calls, and was never ported to OpenGL. In addition, the game uses DirectSound, and other Direct(insert extension) calls. IOW, it's a purely Windows game.
Now the company begins to receive requests like, "Can't you make this OpenGL?" "Have you heard of OpenAL?" "I want to run this awesome game on Linux, and I refuse to buy Windows. I know a dozen friends who'd love to play, but they have the same requirements!"
Our software company is now in a dilemma. What to do? Let's call Loki and see if they can help us. Loki agrees, seeing the potential for an infusion in sales, and begins to port the game to OpenGL, OpenAL, and the SDL libraries. As they work on the code, they find a lot of logic problems, some really nasty bugs, and basic structural problems with the program. They fix these and send it back to the originating software company.
The company is floored. How could we have missed so much? It worked well on Windows, but when we use these standards-based API, it breaks! Let's incorporate these changes and see if we can't make a better Windows product as well.
And thus, the cycle of software improvement continues. The original software company learns some valuable lessons about standards-compliant programming, Loki (or other porters) make some money for the consulting and marketing, and the players, both Linux AND Windows win by getting better software.
No. I don't see porters being in any type of immediate danger. Marketing and business decisions aren't solely based on the Windows phenomenon, they're based on demand. People will continue to demand Linux ports for software because they KNOW that the WineX libs will always be playing catchup with Direct(insert extension). They KNOW that OpenGL, OpenAL, and SDL afford game developers the flexibility of cross-platform compatibility and standards-compliant design. They KNOW that a better product will be the result.
WineX is a good short-term solution, contrary to the author of the article we're replying to. It is not a long-term solution in the eyes of game designers or the consumers in general.
You know. I have the hardest time figuring out who these people are politically, in reference to the people behind this rediculous class-action lawsuit. Are they liberal Democrats or fundy Replublicans? IIRC, the Democrats, liberal or not, are usally on the "stay out of my personal or family decisions" but "fund my needs" side of the argument. The republican fundies are "this is how you should make personal and family decisions" but "stay out of my capitol investment" and "fund it yourself" side of the argument.
The reason I muse over this is because I want to correctly address the right party when I curse them. Based on the above logic, I could say, "Fscking fundies," but I'll refrain. Instead, I'll call them "Fscking clueless jerks."
You can create a Debian package for it. There's nothing stopping you. In fact, Debian does not require GNU licenses. Debian GNU/Linux is referred to in this manner because of the FSF-recognized name for Linux. Likewise, Debian is NOT an FSF distribution. It's close, but software that is distributed in the "main" repository (the free-software repository) must adhere to the Debian Free Software Guidelines (DFSG); it does not necessarily have to be GNUGPL
From the DFSG:
10. Example Licenses
The "GPL", "BSD", and "Artistic" licenses are examples of what we consider free.
Where you will run into problems, or rather where you had run into problems, was with Python 1.6[.1]. Debian refused to package this in "main" for the same reasons its license conflicted with GPL. However, Debian doesn't have the same hangup that FSF has with Python 2+. Just look in the package listing for testing/unstable.
Regardless, I want to clear something up here. If your program depends upon software or libraries that are released under a license that prevents those tools from being distributed in the "main" repository, it does not stop you from packaging your software and including it in "contrib". Your software will not be forced into "non-free" if your license is DSFG-compliant.
Actually, XML is simply a data format for structured data. End of sentance. XML parsers make it much easier to create objects with unique namespaces. It will always be up to the programs to cajole the data into a useable form. These are not, however, parsers. The parsing is complete. This is certainly not a PHB concept; they couldn't think of things so elegant. If you want another buzz word, it's called data-binding. You should seriously check out http://xmlc.enhydra.org and look at XMLC. It works beautifully!
I will agree with your level of frustration with the buzzwordology and incorrect representations of what XML is actually useful for.
And with the advent of Citrix MetaFrame for the Windoze platform, and the promise of reduced administrative costs (even if one has to hire a full time admin to manage it), the focus once again swings around to the thin-client and diskless sytems. Wonderful how technology marketing works, isn't it?
If PHB would just listen to us to begin with, we wouldn't have this cyclical path
The reason LTSP chose the name as it did was because it wanted to appeal to the UNIX-challenged and Micro$oft-influenced market. Windows Terminal Server is a version of NT/2000 that provides remote desktop environments for Windoze compatible clients. It's very spendy and very difficult to keep running efficiently for any period of time. You CANNOT depend upon ONE Windoze Terminal Server being up all the time. You have to do the good ol' server farm that Micro$oft is so famous for.
Interested in providing big businesses an alternative to the cyclical licensing scheme of Micro$oft and it's cohorts, the LTSP crew thought the name Linux Terminal Server Project would appeal to these poor, Micro$oft inflicted Systems Administrators and IT Personel. Its name was not chosen for its more appropriate application in the UNIX and X11 world, referring to serial port dummy terminal servers.
People should remember that you are commenting on market share, not installation share. IMHO, I don't think there will ever be reliable numbers regarding installation statistics.
I think that this post is both insightful and sticks to the point about what the real discussion is: copy control. We all know that Copyright is intended to provide the author of a work the protection of ownership for purposes of recognition and profit control. Yet, that is not the sole application of the copy control features added to PDF documents, as was demonstrated by the parent to this post. Bravo, chill, for staying on discussion rather than entering a diatribe about how Copyright is ruining the Internet.
How many times do we have to tell the "pointy haired boss" that politics does not make good software?! You need to impress upon your boss the fact that all marketing and promises aside, Microsoft Access is not a scalable or stable solution!
When will people learn to delegate responsibility fully to the people who know how to do their jobs best? By not trusting you, the knowledgable staff member, on your design decisions, your management is suffering themselves no small number of headaches for the future of their company. By locking you into an environment that you are 1) not comfortable with, 2) do not trust, 3) doubt will fit the bill, and 4) dislike, they are seeding the crop of their own distruction.
Take a stand. Review your software design goals, and research the proposed tools and environments to do the job. Include in your research their proposals, and work to disprove them based on your own knowledges and instincts. If they can't trust you, their developer, and would rather go with what a marketing drone would recommend, tell them to hire the marketing drone to write the software.
On a less general note, my advise about writing RDBMS-based software:
1) Chose an RDBMS that allows VIEW's, STORED PROCEDURES, or other optimizations that allow the RDBMS to generate and store query plans
Plans are essential tools to efficient queries. Your database management system must decide which indexes it needs to use to fulfill your requests. VIEW's and STORED PROCEDURES are excellent examples of pre-compiled query plans.
A second advantage or use of VIEW's is that of security. VIEW's hide the details of a normalized database and can limit the records viewed from larger datasets. If your design includes ANY type of privaleged users, VIEWS will help you implemnt the security model immensely.
2) Choose an RDBMS that supports TRANSACTIONS
Again, that eliminates MySQL. (Sorry, but it's true.) Some people try to argue that transaction are unnecessary. This may be true with an unnormalized database schema, but when you start to separate the data into its atomic parts, a transaction is essential in tracking the addition, subtraction, or alteration of a set of data that spans multiple tables or records. It is ESSENTIAL for database integrity. I don't trust a program to faithfully rollback a transaction on its own. Computers have hardware problems, programmers blink their eyes as they're searching for bugs. Having an RDBMS that supports TRANSACTIONS isn't a convenience, it's a requirement.
3)Design as many "canned reports" as possible.
There's nothing more frustrating than trying to design a dynamic query builder. Not only do you loose the advantage of having pre-planned queries, but you have also worry about how to best deliver an interface flexible enough to build these dynamic monstrosities. If you don't believe me, take a look at the Bugzilla query page...
4)Choose an RDBMS that supports CURSORS
"Why," you ask? Simple answer. Ever wonder how you're going to limit the result set of a query, especially that one that likes to return 10,000 records even though you will most likely find 50 records to be overwhelming to display on your carefully designed UI? CURSORS provide you a way to page back and forth through a result set withough having to requery the database using MAXROWS options. You may have to hit the database more often to retrieve the results, but the server no longer has to compile a query plan and collect the resultsets. It simply holds the data for you until you need it. Who wants to pass around huge result sets, sucking up bandwidth and memory if you don't need it?
Guess what... This counts out MySQL once again.
5) Do NOT design the business-logic or rules-logic into the CLIENT!
The principals of simple design logic here. If you design your software around the client, then when the rules change in the game of policy (you know, the thing that the "pointy haired bosses" change on a whim, you have to upgrade ALL the installed clients. Guess what? This counts Access out.
What can I say. Access + MySQL sounds like a loosing combination. Access and MSSQL sounds like a better combination, but I would opt for something along the lines of PostgreSQL and Java (though the client-side SWING sucks ass). If you design the application with at least a three-tiered approach, client-server-database, you will be allowed some flexibility in which direction you can migrate with DB selection and client selection.
Anyway, I have to go to sleep so I can get up tomorrow and program... Good luck! Oh, go check out some of the projects like Enhydra.org or jboss.org if Java+Appserver+RDBMS+web raises an eyebrow or two.
Firtly, yeah! Why? Because Debian is starting to do what I thought they should do for some time now. Release cycles should be done in phases. I cannot agree more with the outline that AJ has set up. The one thing I would add to that would be, "And when we finally release woody as stable, we will start all over for the next release."
If it so happens that by the time that Woody is released in toto, that the next generation boot floppies are still not ready for release, we fall back to the versions used in the last release. I know that no one will want to do this, and thus we may have the motivation to finish up TNG-boot floppies, but why would we ever want another 1.5 - 2 year release cycle?
The first steps have been made: "testing", autobuilders, and phase-based release freeze. Now, let's keep it going w/a 12 month continuous release cycle.
There are a number of problems that arise when a commercial entity tries to sell a free distribution such as Debian.
Selling what you could otherwise get for free..
What do you think is going through the mind of a Stormix or Corel customer? "Why am I paying Corel for Debian when I can simply install and maintain it for free by going directly to Debian?"
Commercial distributions (forks) often break packages
We saw this with Corel. They worked to create a commercial version of Debian, making custom packages that often break dependencies with packages from Debian proper. This makes it difficult to maintain an machine with packages that have cross-dependencies between the commercial entity and Debian proper. The helix-gnome packages are another example of this.
The thing these entities do not realize is that if they feel a package must be "updated", simply providing a Non-Maintainer Update or patch is often the fastest and easiest way to update Debian, rather than forking the distribution and trying to maintain compatibility between them.
The Debian Project has different goals than a commercial entity
When the roadmap that the commercial entity requires its product to be at a certain stage at a certain time, having a product that it does not maintain internally becomes largely problematic. A company may be willing to become an integral member of the Debian community, contributing its time, money, and resources to improving Debian proper. Yet, when the community does not agree or comply with the desires of the company, it's often a hard pill to swallow. What do you tell your customers and investors when you fail to move Debian in the direction you would like to go?
This symbiotic relationship requires a very open mind by the commercial entity. It has to be willing to accept the ebb and flow of Debian proper, and disregard what the company may traditionally view as a loss of time and resources. Instead they have to look at the glass as half-full, not half-empty, and make the best of the situation. Most companies are not willing to do that, and most investors do not like to see their money "squandered".
What commercial model "works" with Debian?
That's the million-dollar question, isn't it? Perhaps taking queues from Progeny Linux would help in answering this question. Perhaps look at
LinuxCare's support models. IMHO, Debian should be viewed as a centerpiece tool for support models rather than a focus for a product model. It simply will not integrate well as the latter, but can work quite well in the former. "Our Developers work as members of the Debian Project and the Open Source community to bring you the most reliable, stable, and useable distribution of Linux available. When we find problems or bugs, we will not only provide you with timely fixes, we will give these fixes back to Debian in that same prompt manner."
Slashdot Mirror
I bet your life revolves around computers right now, doesn't it? You go to school and are saturated by computers and CS work. You go home and you're once again saturated with computers and CS homework. Hey, everyone burns out sooner or later. The key to keeping your interest in CS is to find a hobby that has nothing to do with your love for computers. Seriously.
Monotony can be mind-numbing, and can add on more than a few pounds to your already growing arse -- we call that "programmer's arse" (remember, a can of pop has 170 useless calories that go straight to your rear).
So, go out and do something. Take a break for cryin' out loud! Winter is coming shortly up here in the midwest, and I'm biting at the reigns to go cross-country skiing. In the mean time, it's rollerblades, walks, or learning how to play guitar.
I may be a geek, but I'm not a 24/7/365 keyboard-slave!
That's great except when Joe lawnmower ruins all your fun.
Posted by CmdrTaco himself back in January. Has anything new been brought to the table about this? No. Come on, people. Just because news is a bit slow doesn't mean we have to resort to digging up old news.
Besides, with the advanced routing techniques available to Linux/UNIX/BSD style boxes, you don't have to be the sole upstream provider. You can peer amongst other Wireless users that have a full/part-time connection to the Internet. Imagine redundancy over multiple users whose ISP's in turn have redundant connections over multiple networks using diverse methods of connectivity (Cable, xDSL, Modem, Leased Lines, Wireless, T1/T3, etc). Add in QOS rules to classify, route, and limit traffic. If one of you gets picked out for incorrect bandwidth useage, you're not out of the game. You may have added latency and reduction in local bandwidth resources, and your community members would have lost a fraction of their total bandwidth. Guess what, you still win; you're still connected.
And thusly, the cycle of war continues. Strike and strike back. Notice how revenge is the only motivation necessary to continue spreading human blood. No longer is religion or culture involved, just the archaic desire for violence. I have little faith that we, as a species, ever evolve past such emotional "knee jerk" reactions.
Violence begets violence, and unfortunately, it is sometimes necessary. I fully support an organized and decisive action against the terrorists. Not for revenge or other basal needs, but for ultimate peace and order and the protection of the living.
It's great that people wish to write applications and operating systems in assembly. They possess a greater knowledge of the hardware layer of the computer than I, and a greater need for the abstract. Given the choice, C is my preferred language. It allows me to concentrate on the application side of things, yet gives me enough low-level control that I can do hardware specific instructions w/o having to enter the assembler.
Assembly has its uses, especially in code optimization, and it will probably never go away for that same reason. It is certainly a "no nonsense" approach to programming, and ideal for embedded applications.
We know there's a difference between the term Open Source and Free Software. It is conceivable that Progeny may Open Source the software sometime in the future, but one of the reasons they are developing this internally is so they can have more control over the direction of the project. Once the software is in the Alpha stage, I bet we'll see it. Still, I wouldn't begin to guess at what type of licensing scheme they'll use. They may even surprise us and GPL it. Then again, we're talking Ian Murdock here. It may not be a surprise at all if they GPL it. ;-)
Sadly, this observation flies true to its target sometimes. Other times, you get observant people who realize that proprietary != bad. Remember, proprietary != closed-source in all cases. There seems to be a general agreement that the technical definition of Open Source does not choose sides as to whether a software product is proprietary or not. On a similar thread, Loki has demonstrated that a software company CAN work on proprietary software while contributing to GNU or the Public Domain, take SDL for example.
When finances permit, I have and will continue to support Loki Software by purchasing the fruits of their labor. Even if it is for a money-sucking Microsoft-loving company like Sierra. At least they figured out that there WAS a market in the Linux crowd. Don't confuse growing pains with utter failure, people. Loki isn't down for the count just yet!
How can you compare a hardware/computer distributor to a software company? They're entirely different beasts. All of my personal dislike of Dell aside (<troll>they build shitty computers</troll>), a personal computer can easily be built for less than the average $1000 price tag Dell wants to extract from your wallets. Regardless, it's rare that any Linux install lasts very long at the receiving end of my keyboard. You think I'll trust someone else touching my machine??? <Insert control-freak explicative here>
Let's bring the conversation back to the real competition in question, software vendors. There is something to be said about supporting companies that not only support your favorite operating system, but provide positive influence to the design and gameplay of your favorite computer games.
I've said it before, and I'll say it again. Software benefits from the "many-eyes" approach to design. That's part of the reason why OSS projects are generally successful. Software company "A" hires software company "B" to port their code to another operating system. Not only does software company "B" act as a code auditor, it acts as positive and constructive feedback to the original game manufacturer. Software engineering improves, software designers skills improve, games improve, enjoyment improves.
Ah, but I've said this all before. I for one will support Loki when I can actually afford to buy another game. I've been eyeballing a few, but you know, life and its responsibilities get in the way of entertainment sometimes.
It's really hard to follow this one up with anything but an, "I agree." Perhaps this is a useless post, but to add to the show of hands and answer the question, all the music I rip from CD goes to OGG. MP3's just don't sound as good. There are sounds that you can hear in the CD recording and the OGG encording that you cannot hear in an MP3. Sorry, MP3 fans.
That should be sufficient for allowing software vendors to feel comfortable packaging for Debian with rpm's. Of course, the use of a packaging system does not alleviate the problems with dependency resolution and binary to library incompatibilities. Vendors will still need to be careful to recompile their rpm's in the environment they expect to deploy the software. One thing that is nice about LSB is that we will know where to find the software files when they ARE installed.
--
The definition of Open Source, as detailed in the Licenses in question is as follows.
These clauses say nothing about disallowing distribution or use on "non-free" operating systems as the original poster implied. Review definition above and compare it to the word "non-free".
Additionally, Open Group is willing to provide an alternative license for the software, as stated by the License. This caveate emptor is very similar to what Trolltech used to do with Qt. It is also a clause that keeps the Open Group API and software in the "non-free" branch of Debian. For example, this is the information on the libmotif package:
--
No one takes them seriously in that market yet since you can only do single CPU systems.
We can blame this on the motherboard manufacturers more so than AMD. AMD has designed a superior processor, the specs and an example chipset to run the thing. Any chipset manufacturer should be able to get the specs to design their own chipsets to work with the Athlons in single, dual, quad, whatever. The motherboard manufacturers are lazy, getting plump on their multiprocessor Intel income, or getting pressure from Intel to drag their feet -- which Intel has been known to do on more than one occassion.
It is certainly disappointing that it has taken this long for a serious attempt at retail multiprocessor boards for the Athlon to appear. Perhaps next year, when they've worked out the bugs, and when I've got a little more mula, I'll look into them.
--
The game releases, and as predicted it's a great success. Linux users are envious, but dislike having to dual boot their boxes. Emulation is not quite there for this new game, as it uses a bunch of Windows-centric, bleeding-edge DirectX calls, and was never ported to OpenGL. In addition, the game uses DirectSound, and other Direct(insert extension) calls. IOW, it's a purely Windows game.
Now the company begins to receive requests like, "Can't you make this OpenGL?" "Have you heard of OpenAL?" "I want to run this awesome game on Linux, and I refuse to buy Windows. I know a dozen friends who'd love to play, but they have the same requirements!"
Our software company is now in a dilemma. What to do? Let's call Loki and see if they can help us. Loki agrees, seeing the potential for an infusion in sales, and begins to port the game to OpenGL, OpenAL, and the SDL libraries. As they work on the code, they find a lot of logic problems, some really nasty bugs, and basic structural problems with the program. They fix these and send it back to the originating software company.
The company is floored. How could we have missed so much? It worked well on Windows, but when we use these standards-based API, it breaks! Let's incorporate these changes and see if we can't make a better Windows product as well.
And thus, the cycle of software improvement continues. The original software company learns some valuable lessons about standards-compliant programming, Loki (or other porters) make some money for the consulting and marketing, and the players, both Linux AND Windows win by getting better software.
No. I don't see porters being in any type of immediate danger. Marketing and business decisions aren't solely based on the Windows phenomenon, they're based on demand. People will continue to demand Linux ports for software because they KNOW that the WineX libs will always be playing catchup with Direct(insert extension). They KNOW that OpenGL, OpenAL, and SDL afford game developers the flexibility of cross-platform compatibility and standards-compliant design. They KNOW that a better product will be the result.
WineX is a good short-term solution, contrary to the author of the article we're replying to. It is not a long-term solution in the eyes of game designers or the consumers in general.
--
You know. I have the hardest time figuring out who these people are politically, in reference to the people behind this rediculous class-action lawsuit. Are they liberal Democrats or fundy Replublicans? IIRC, the Democrats, liberal or not, are usally on the "stay out of my personal or family decisions" but "fund my needs" side of the argument. The republican fundies are "this is how you should make personal and family decisions" but "stay out of my capitol investment" and "fund it yourself" side of the argument.
The reason I muse over this is because I want to correctly address the right party when I curse them. Based on the above logic, I could say, "Fscking fundies," but I'll refrain. Instead, I'll call them "Fscking clueless jerks."
--
From the DFSG:
Where you will run into problems, or rather where you had run into problems, was with Python 1.6[.1]. Debian refused to package this in "main" for the same reasons its license conflicted with GPL. However, Debian doesn't have the same hangup that FSF has with Python 2+. Just look in the package listing for testing/unstable.Regardless, I want to clear something up here. If your program depends upon software or libraries that are released under a license that prevents those tools from being distributed in the "main" repository, it does not stop you from packaging your software and including it in "contrib". Your software will not be forced into "non-free" if your license is DSFG-compliant.
So, start packaging!
--
--
I will agree with your level of frustration with the buzzwordology and incorrect representations of what XML is actually useful for.
--
And with the advent of Citrix MetaFrame for the Windoze platform, and the promise of reduced administrative costs (even if one has to hire a full time admin to manage it), the focus once again swings around to the thin-client and diskless sytems. Wonderful how technology marketing works, isn't it?
If PHB would just listen to us to begin with, we wouldn't have this cyclical path
--
Interested in providing big businesses an alternative to the cyclical licensing scheme of Micro$oft and it's cohorts, the LTSP crew thought the name Linux Terminal Server Project would appeal to these poor, Micro$oft inflicted Systems Administrators and IT Personel. Its name was not chosen for its more appropriate application in the UNIX and X11 world, referring to serial port dummy terminal servers.
--
--
--
How many times do we have to tell the "pointy haired boss" that politics does not make good software?! You need to impress upon your boss the fact that all marketing and promises aside, Microsoft Access is not a scalable or stable solution!
When will people learn to delegate responsibility fully to the people who know how to do their jobs best? By not trusting you, the knowledgable staff member, on your design decisions, your management is suffering themselves no small number of headaches for the future of their company. By locking you into an environment that you are 1) not comfortable with, 2) do not trust, 3) doubt will fit the bill, and 4) dislike, they are seeding the crop of their own distruction.
Take a stand. Review your software design goals, and research the proposed tools and environments to do the job. Include in your research their proposals, and work to disprove them based on your own knowledges and instincts. If they can't trust you, their developer, and would rather go with what a marketing drone would recommend, tell them to hire the marketing drone to write the software.
On a less general note, my advise about writing RDBMS-based software:
What can I say. Access + MySQL sounds like a loosing combination. Access and MSSQL sounds like a better combination, but I would opt for something along the lines of PostgreSQL and Java (though the client-side SWING sucks ass). If you design the application with at least a three-tiered approach, client-server-database, you will be allowed some flexibility in which direction you can migrate with DB selection and client selection.
Anyway, I have to go to sleep so I can get up tomorrow and program... Good luck! Oh, go check out some of the projects like Enhydra.org or jboss.org if Java+Appserver+RDBMS+web raises an eyebrow or two.
--
Firtly, yeah! Why? Because Debian is starting to do what I thought they should do for some time now. Release cycles should be done in phases. I cannot agree more with the outline that AJ has set up. The one thing I would add to that would be, "And when we finally release woody as stable, we will start all over for the next release."
If it so happens that by the time that Woody is released in toto, that the next generation boot floppies are still not ready for release, we fall back to the versions used in the last release. I know that no one will want to do this, and thus we may have the motivation to finish up TNG-boot floppies, but why would we ever want another 1.5 - 2 year release cycle?
The first steps have been made: "testing", autobuilders, and phase-based release freeze. Now, let's keep it going w/a 12 month continuous release cycle.
--
There are a number of problems that arise when a commercial entity tries to sell a free distribution such as Debian.
Selling what you could otherwise get for free..
Commercial distributions (forks) often break packages
The Debian Project has different goals than a commercial entity
What commercial model "works" with Debian?
--