Dear Developers,
I was wondering. Currently SUSE 11.0 is excellent. Has a great interface and heads into the right direction. Focus on mass market and open standards, not source, development. The idea is to maybe* not focus* on closed source, but approach it as closed source. The source is then closed but still available if you ask the SUSE 11.0 developers for it. Developers will be fully supported in a terrific developers network where they pay for a developers package, but the kernel and operating system is closed source.
[kernel and system tools]<closed source (system packaging)
[developers environment]<open source (specialised packaging)
How would one go about testing closed source SUSE 11.0?
What is the best roadmap for closed source SUSE 11.0?
Can we sell- and develop software with closed source?
Will it be beyond hello world or what’s your name?
SLED/SLES fundamentally are. What you suggest openSUSE seems to be sort of the test/development version, yet a distro in its own right.
The Linux kernel is under the GPL which requires that the sources for any binaries released be available for reasonable costs of copying. So it cannot be closed. Neither can any of the other OSS.
In any case you are approaching it from the wrong angle. The value is in the support. Just having the source is only a small part of it. Ask Wall Street why they are willing to pay for support.
Yes, good remark, I meant the difference between a closed source environment with binaries only and open source development. Without support. Without or with less support you remove a some very high costs and can cut costs while at the same time making money.
- more hardware
- working system
- less interference
- better cooperation
- obfuscation clarity
- less confusion
- better usability
- reliable testing
- stored feedback
- grand measurement
- system convergence
- better sales
Step I
The trick is to gather as much information about as much hardware as you can and test the io states of all that hardware. Feedback is sent on the network and checked if gathered states are working on virtualised hardware or hardware. Simple tests like, does audio work, does graphics work, does cards work. Then from that you can create a neural grid network that chooses the best average system they should be working on such a system.
Step II
The trick is to install as many commercial applications as possible on functional systems and test usability of those applications. This is the stage that I am currently at, together with the first step. I noticed that you can converge the system to a desktop environment. No strings attached no deals with third party developers developing for example telephony applications. This should lead to better application and developer support.
Joe-barriere wrote:
> Dear CrackHead,
>
> Get a freaking clue.
>
>
Please do not attack other members as this is against the T&C’s.
