== Size == * The source code is more than 100 MB. [ +5 points of FAIL ] * If the source code also exceeds 100 MB when it is compressed [ +5 points of FAIL ]
125372299 Jul 22 00:36 linux-4.1.3.tar.gz
== Source Control == * You've written your own source control for this code [ +30 points of FAIL ]
git was written originally for Linux kernel!
== Building From Source == * Your source is configured with a handwritten shell script [ +10 points of FAIL ]
Even worse: handwritten C program: scripts/kconfig/mconf that is compiled and run by "make menuconfig".
== Bundling == * Your source only comes with other code projects that it depends on [ +20 points of FAIL ] * If you have modified those other bundled code bits [ +40 points of FAIL ]
Compression and encryption libraries, for example.
== Libraries == * Your code only builds static libraries [ +20 points of FAIL ] * Your source does not try to use system libraries if present [ +20 points of FAIL ]
Not even glibc!
== Code Oddities == * Your code depends on specific compiler feature functionality [ +20 points of FAIL ]
Lots of places where gcc-specific code is used.
== Licensing == * Your code does not have per-file licensing [ +10 points of FAIL ]
=== FAIL METER === Total: 180, highest possible: 135+ points of FAIL: So much fail, your code should have its own reality TV show.
OK, Russia is corrupt and doesn't care of botnets. But Estonia is the EU member. Instead of shutting down C&C servers, they should have obtained a court order to seize at least one of C&C servers and use it to retrieve the secret key used to sign commands. Then this key could be used to kill the whole botnet.
OK, you solve problem for GUI apps, but for CLI apps you still need some kind of package management. Also, you need package management for system services, like database servers, mail, DNS, NTP, etc. Otherwise, how do you know which file belongs to which software package and how can you remove/upgrade packages? But if you already have package management system, why not to use it for GUI apps also?
OK, Let's count advantages and disadvantages of proposed software installation system.
Advantages:
You can easily know which files belong to which software packages
You can easily remove the entire package by using simple rm -r command
All these goals can be easily achieved using any reasonable package menegement system. Now let's see disadvantages:
Every time you install package you have to change PATH variable. Existing applications must be restarted to see this change, because environment variables are inherited and can be changed on-the-fly only if application itself is shell or has some shell-like functionality.
Many packages have variable files (logs, data, caches, pipes etc.), which are normally placed in/var directory. Often/var resides on separate filesystem, because it has different requirements for speed, reliability, backup and other criteria. Under proposed schema we can not have separate variable filesystem.
Shared library dependencies become a nightmare. If you have no version number in package directory name, you can not install different versions of shared library, so forget about compatibility with old packages. If you have version number, library moves to different place every time you upgrade package. Don't forget, that shared library version numbers do not necessarily reflect package version. Instead, they reflect ABI changes.
Where are you going to have configuration files? If in the package directory, you must copy them every time you upgrade package. If for some reason you decide to remove package and than install it again, you lose all package's config files.
You have problems if you decide to split package into subpackages. Directory structure changes and all applications which use programs or libraries from splitted package must be updated or restarted. The same problem exists when you unite packages together (like fileutils, sh-utils and textutils was united into coreutils package).
Relying on PATH environment variable for invoking another programs is somtimes dangerous, especially for system services and set-UID programs. Usually full pathname is used in these cases. What kind of pathname can be used under proposed schema, if invoked program's package name can be changed (splitted into separate packages, united) or program can be moved from one package to another?
So, what we gain? Nothing. There are some advantages which can be easily achieved another way, but there are very serious disadvantages. When managing system, stop thinking in terms of files. Think in terms of software packages. Consider/usr/bin a namespace which contains user-level programs and which is populated when packages are installed. Consider/usr/lib a namespace which contains libraries.
RoverBook Voyager FT5 with Linux pre-installed
on
Which Laptop To Buy?
·
· Score: 1
It's interesting to note that Russian company
Belyi Veter (White Wind) sells laptops with
Linux pre-installed just for $995.
Configuration is good enough:
1024x768 13" TFT LCD
Celeron 633MHz
64MB SDRAM
10GB IDE HDD
Built-in (unfortunately, software AFAIK) modem
10baseT/100baseTX ethernet
24X CD drive
For those who can read Russian, more info is available
here
.
It would be interesting to hear impressions of those who already have such device, because I'm thinking about buying one.:-)
Hello Slashdot community!
This is my first post here, so please don't blame me much.
Currently I'm working on a billing sistem for a large ISP. This billing system is conceptually different from existing solutions because it is designed to be as flexible as possible and handle arbitrary services and billing plans.
The core of this system is a temporal data storage, which looks to the outside programs like an SQL server with the SQL-like request language providing some interesting features:
Object-oriented tables with methods.
For example, you can create a generic service with generic methods to calculate service costs and stuff, and than construct arbitrarily complex services inherited from generic one.
Change history is available for both reading and writing.
You can read the history of attributes, see the state at any requested point of past and even add events to the past or remove ones.
Such data storage makes writing complex billing systems very simple task. I'm considering to make this server open source. Hence, I want to ask Slashdot Community: will such system be interesting to you?
The preliminary documentation is available
here
.
Unfortunately, this documentation is not up-to-date, the development is going rapidly and documentation sometimes doesn't keep up with changes.
Slashdot Mirror
I should have put large <humour> ... </humour> tags around my comment.
I found quite ironic that a project that could have been _formally _ assigned so many fail points has not failed in any meaningful sense of fail.
== Size ==
* The source code is more than 100 MB. [ +5 points of FAIL ]
* If the source code also exceeds 100 MB when it is compressed [ +5 points of FAIL ]
125372299 Jul 22 00:36 linux-4.1.3.tar.gz
== Source Control ==
* You've written your own source control for this code [ +30 points of FAIL ]
git was written originally for Linux kernel!
== Building From Source ==
* Your source is configured with a handwritten shell script [ +10 points of FAIL ]
Even worse: handwritten C program: scripts/kconfig/mconf that is compiled and run by "make menuconfig".
== Bundling ==
* Your source only comes with other code projects that it depends on [ +20 points of FAIL ]
* If you have modified those other bundled code bits [ +40 points of FAIL ]
Compression and encryption libraries, for example.
== Libraries ==
* Your code only builds static libraries [ +20 points of FAIL ]
* Your source does not try to use system libraries if present [ +20 points of FAIL ]
Not even glibc!
== Code Oddities ==
* Your code depends on specific compiler feature functionality [ +20 points of FAIL ]
Lots of places where gcc-specific code is used.
== Licensing ==
* Your code does not have per-file licensing [ +10 points of FAIL ]
=== FAIL METER ===
Total: 180, highest possible:
135+ points of FAIL: So much fail, your code should have its own reality TV show.
Sorry, the wrong subject. I mean, Nokia N900.
They missed the most important event of the year: launch of Nokia N900.
OK, Russia is corrupt and doesn't care of botnets. But Estonia is the EU member. Instead of shutting down C&C servers, they should have obtained a court order to seize at least one of C&C servers and use it to retrieve the secret key used to sign commands. Then this key could be used to kill the whole botnet.
OK, you solve problem for GUI apps, but for CLI apps you still need some kind of package management. Also, you need package management for system services, like database servers, mail, DNS, NTP, etc. Otherwise, how do you know which file belongs to which software package and how can you remove/upgrade packages? But if you already have package management system, why not to use it for GUI apps also?
Advantages:
All these goals can be easily achieved using any reasonable package menegement system. Now let's see disadvantages:
So, what we gain? Nothing. There are some advantages which can be easily achieved another way, but there are very serious disadvantages.
When managing system, stop thinking in terms of files. Think in terms of software packages. Consider
It's interesting to note that Russian company Belyi Veter (White Wind) sells laptops with Linux pre-installed just for $995.
Configuration is good enough:
For those who can read Russian, more info is available here . It would be interesting to hear impressions of those who already have such device, because I'm thinking about buying one. :-)
Hello Slashdot community! This is my first post here, so please don't blame me much.
Currently I'm working on a billing sistem for a large ISP. This billing system is conceptually different from existing solutions because it is designed to be as flexible as possible and handle arbitrary services and billing plans.
The core of this system is a temporal data storage, which looks to the outside programs like an SQL server with the SQL-like request language providing some interesting features:
Such data storage makes writing complex billing systems very simple task. I'm considering to make this server open source. Hence, I want to ask Slashdot Community: will such system be interesting to you?
The preliminary documentation is available here . Unfortunately, this documentation is not up-to-date, the development is going rapidly and documentation sometimes doesn't keep up with changes.
Will be glad to hear your comments.