Check out my latest product, BuildFactory
Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/globalfunctions.php on line 779
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/BLOG.php on line 170
i hate open source, sort of.
Warning: Parameter 1 to NP_Geshi::event_PreItem() expected to be a reference, value given in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/MANAGER.php on line 331
Whisper it with me one time "open source." Now think about that, is that not the most miserable term you've ever heard? You thought that was bad, how about a question I've read enough times to kill a moose: "is it free as in speech, or free as in beer?" The entire concept of "open source" is a concept I thought of right after Al Gore invented the internet, and it has led to more headaches, more flamewars, and more phosphor green light emitted from my monitors than anything else. I joyfully participate in projects that can be considered "open source" in my spare time, time that is when I should probably be doing actual work, but I still inevitably come to the conclusion "GAWD! OPEN SOURCE SUCKS!!!!" after shouting this in a hushed voice in my office, I come to the scariest realization a young programmer will ever have:
this is the best we've got
Does that send shivers down your spine too? But let's face reality here, you know what happens when we let corporations close up development of their systems? Mac OS 9 (yuck!), Windows XP SP2 Lite Beta Professional++ (double yuck!), and then more commercial unix-y systems like SCO Unix (I've had to do development on OpenServer before, it's fucking sick), and before a year or so ago, Solaris (I remember SunOS, and I still remember when Solaris sucked, some might argue it still does). I remember having to zap my PowerMac 6100's PRAM to fix some wonky bug, I remember having to reinstall Windows on my PC to get it to...work, I remember having to recompile the SCO Unix OpenServer kernel because I wanted the network interface to receive a DHCP lease instead of a static IP address, I remember using university Solaris servers for some CS projects; they all have something in common, they all fucking suck (expletives have been left in for emphasis, and rhythmic effect).
things are going to get a lot worse, before things get worse.
One of the key components to any operating system is going to be its package management tools. Every modern operating system not counting Microsoft's Windows has a decent package management toolset built in, some even have two or three! With the exception of Mac OS X's "application bundle" approach, they all suffer from similar sets of problems regarding conflicts, dependencies, upgrading, and making toast. One of the first reasons I switched from redhat (8!) to FreeBSD came after I was sitting in my home office staring at the results of an rpm --install command where the (paraphrased) output in my Xterm stated "package xyz depends on package zyx", so I attempted to install the 'zyx' package only to get the outputs stating "package zyx depends on package xyz." After a good 45 minutes sitting, crying, in the shower, I set out for a new bit of territory in the vast deserts of "open source" trying vainly to find an oasis of sanity. Of course, I was entering the university around this time, and word on the street of 'Engineering Row' was that "Debian is the kewlest" and thusly I downloaded and installed Debian.apt-get install kitchen-sink-0.2.4
I'm a big fan of the debian package management system, which revolves around dpkg, and apt-get. It's a magnificent system, and a good one for the Fink project to base their work around. Sadly for those who are unable to purchase liquor, all the wondrous package management in the world doesn't fix dependency-hell. Just look at the package information page for devel/subversion. Just to install subversion you need to install 13 dependencies, granted some of them like "libc" you'll probably have, some of them may or may not conflict with other installed versions of libexpat, libxml2 or even libneon. This is for one application, granted a reasonably complex one, what about for an entire desktop system, like KDE? Pop open a terminal, and as a super-user run apt-get install kde, and go into town for some coffee, and maybe some shopping, and maybe even an afternoon picnic followed by a late dinner at a small bistro downtown. By the time you get back, provided there weren't any show-stopping conflicts, you might have KDE installed, and if you're even luckier, it'll run. There are ways around conflicting dependencies, or a different version of perl being incompatible with the one needed to install a large package, but not everybody is cut out for the heavy drinking and banjo-playing that it requires; basically, if conflicts do arise, cry yourself to sleep and when you wake, go buy a Mac.i'm pretty sure that daemon is evil
After growing weary of GNU/Linux and all it's GNU/Problems, I decided to switch to FreeBSD, hearing rumours about how fantastic it's ports system was that even those well-spoken, outstanding citizens of the gentoo persuasion based their package management system off of it. After using sysinstall(1) to install loads of wondrous binary ports I became aware of one of the most disgusting things I've ever seen...everything and it's mother has perl as a dependency, seriously see for yourself Of course, some of them require different versions than others, and some versions conflict with each other, and some other versions still refuse to install, and in the end your ears start to bleed and you decide that maybe you'll just build MySQL, and Apache from source just to prevent further blood loss. I've gone so far into the realm of absurdity, when i try to run xlogo(1) over a SSH X11 tunnel I get this:%xlogo
/libexec/ld-elf.so.1: Shared object "libexpat.so.5" not found, required by "xlogo"
%
/libexec/ld-elf.so.1: Shared object "libexpat.so.5" not found, required by "xlogo"
%
I'm by no means a FreeBSD novice, I have access to the perforce repository for the FreeBSD project (to my own work in it), and somehow I even can be reached via email at tyler@freebsd.org. I don't regularly require X11 for my FreeBSD machine, so i've not bothered fixing the problem, I just like to refer back to it when I gripe about ports. I feel that complete ignorance of a solution is usually the best way to form an opinion it seems, especially in regards to "open source." ;)
insert tab 'a' into slot 'b' and give up
The completely illogical and short-sighted solution would be of course to stop using "open source" altogether. Unfortunately, the only good software on Windows is usually "open source", and my work depends on leveraging "open source" on the Mac platform for the most synergetically collaborative cutting edge agile solution possible. With the advent of universal binaries, and the need to have my products compatible both on Mac OS X/ppc and Mac OS X/intel machines, my nightmare worsens. There are a lot of projects (I'm looking at you KDE) that are hard enough to get compiling correctly on a Mac to begin with, now I have to compile them for two architectures, and make sure they link against cross-platform libraries (usually that need to be built as well), AND then make sure it runs on both platforms too? Oh gee whiz mister, instead of that basket of muffins wrapped in rainbows, can you just hit me over the head with a plank instead? No amount of DarwinPorts magic, or Fink wizardry is enough to keep an up to date set of "open source" libraries installed, universal, stable, and non-conflicting enough for general development. Trust me, I've tried, I've tried again, I've wasted an entire day trying, and I cannot get the vile sour taste out of my mouth because after over a decade of progress in "open source" this is still the best we've got, and it kind of sucks.[tags: apple, opensource, linux, freebsd, sco]
Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/globalfunctions.php on line 779
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/ITEM.php on line 61
Replies
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
Geez, I use Debian Stable, which doesn't seem to suffer from any dependency hell problems. - Note: I'm a redhat refugee
If you are developing software on the bleeding edge, then stop bitching - that's the way things go.
If you are developing software on the bleeding edge, then stop bitching - that's the way things go.
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
Try Kanotix (based on unstable branch of debian),it has most cutting-edge versions of sw already installed.
Then go into /etc/apt/sources.list and comment out lines for Unstable,but leave Testing or Stable for more stability with any new packages you add.
Also from Kmenu (in lower left corner of desktop), choose "Applications (installed by klik) to download apps in monolithic form, i.e. dependencies included in download.
Then go into /etc/apt/sources.list and comment out lines for Unstable,but leave Testing or Stable for more stability with any new packages you add.
Also from Kmenu (in lower left corner of desktop), choose "Applications (installed by klik) to download apps in monolithic form, i.e. dependencies included in download.
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
ok, what is it with these web pages that scroll at a snail's pace and kick CPU usage into the stratosphere? goshalmighty, it is possible to post one's deep thoughts in a non-sucky manner.
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
Had the same problem with libexpat.so.5, and ended up telling rc.conf where to find it, as well as the package that required it. Works now without complaint; go FreeBSD Newbie!
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
The wheels came off as soon as they started using those evil shared libraries.
Compile static and save the world!
Disk space is cheap.
Compile static and save the world!
Disk space is cheap.
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
If, when intsalling RPMs and you have that dependency problem, try
rpm -Uvh *.rpm
to install all the RPMs in that directory together and they will see they have the dependencies to complete the install. Check the man page, i think that's right.
rpm -Uvh *.rpm
to install all the RPMs in that directory together and they will see they have the dependencies to complete the install. Check the man page, i think that's right.
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
ha ha ha. Brilliant. open source is a bit like democracy; it sucks, but it is the best thing we have
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
Yeah, well you should have been here when all there was to work with was 8086 assembler or GW Basic. If you don't like the way things are, fix them. Whining is for infants.
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
It seems like the complaint is more about the shared library "culture" of OSS specifically, not OSS in general.
In the OS that almost everyone uses, of course, applications are typically distributed with the application and libraries installed under application-specific folders, thus reducing the dependency on shared libraries. (On my work PC, which is limited to only having employer-approved software on it, there are around 4,000 DLLs under <\Program Files>.)
Given this localized approach, you can even install multiple versions of an application, using different versions of libraries, on the same machine.
This approach has its own problems, of course (e.g., proliferation of files/lack of reuse), but it hides the issue of complexity from the user. The only problem the user typically sees is the increased overhead of the Registry system.
I haven't perused the GPL in a while, but I suspect the library protocol is mostly cultural, not legal. It seemed elegant, in some ancient time, to reuse library code by putting it in a common place and prohibiting anyone else from having privatized/localized versions of that code. After tens of thousands of individuals started adding code, however, this solution quickly became inelegant in its own way.
I have read that PC-BSD uses the privatized model for its packages, whereas DesktopBSD (both are poorly named for desktop OS, ironically) continues to use the collectivized model. It should be interesting to see how well the former takes hold.
In the OS that almost everyone uses, of course, applications are typically distributed with the application and libraries installed under application-specific folders, thus reducing the dependency on shared libraries. (On my work PC, which is limited to only having employer-approved software on it, there are around 4,000 DLLs under <\Program Files>.)
Given this localized approach, you can even install multiple versions of an application, using different versions of libraries, on the same machine.
This approach has its own problems, of course (e.g., proliferation of files/lack of reuse), but it hides the issue of complexity from the user. The only problem the user typically sees is the increased overhead of the Registry system.
I haven't perused the GPL in a while, but I suspect the library protocol is mostly cultural, not legal. It seemed elegant, in some ancient time, to reuse library code by putting it in a common place and prohibiting anyone else from having privatized/localized versions of that code. After tens of thousands of individuals started adding code, however, this solution quickly became inelegant in its own way.
I have read that PC-BSD uses the privatized model for its packages, whereas DesktopBSD (both are poorly named for desktop OS, ironically) continues to use the collectivized model. It should be interesting to see how well the former takes hold.
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
>...but I suspect the library protocol is mostly cultural, not legal.
>
Besides saving memory and disk space, which are admittedly less of an issue, consider also bugfixes and security updates.
For apps that have many small libraries that are not as commonly used as say, C or X libs or the major widget toolkits, I agree that monolithic downloads should be available as an option, to those users who may just want to try out an app, or who just don't care to hunt down dependencies. (e.g. security issues not as critical for non-networked app on single-user computer).
>
Besides saving memory and disk space, which are admittedly less of an issue, consider also bugfixes and security updates.
For apps that have many small libraries that are not as commonly used as say, C or X libs or the major widget toolkits, I agree that monolithic downloads should be available as an option, to those users who may just want to try out an app, or who just don't care to hunt down dependencies. (e.g. security issues not as critical for non-networked app on single-user computer).
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
...and of course they could also download full security update from where they got monolithic app, though if the library in question were commonly used, such as say, zlib, then this might be cumbersome.
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
I think you fuck it up because you CAN. With most things, you get fucked-up shit handed to you, with OSS, you get to be the fucker, AND the fuckee.
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
This is hands down the best and most accurate article I have ever read about open source and, perhaps, programs in general. It is great to hear from someone who sound like they have spent some "quality time" with computers and programming.
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
more suggestions:
-develop in mono (entire framework self-contained, monolithic download available)
-develop in tiny simple packages (the KISS principle), eg. Lua + WXWindows + C
-use highly-evolved frameworks like ruby/jruby + rails
You're a programmer right? Fix it, don't whine!
-develop in mono (entire framework self-contained, monolithic download available)
-develop in tiny simple packages (the KISS principle), eg. Lua + WXWindows + C
-use highly-evolved frameworks like ruby/jruby + rails
You're a programmer right? Fix it, don't whine!
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
p.s. if you insist on programming in the absolute latest cutting-edge KDE components, you are creating almost as bad a problem as what you are whining about for users who will presumably try to download and install dependencies for your amzing piece of SW.
think about it.
think about it.
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
The problem is "repository culture", which I am sad to say will remain with us forever until we get package managers that make a clear distinction between what is considered the OS (and therefore always available and shared), that which is extra services and applications (which should be DELETED from the OS repository).
Then all that lib* stuff which did not make it into the current Standards Base gets statically linked-in (or otherwise physically included) by the application programmer who then assumes responsibility for the WHOLE package (especially distributing it).
Voila! Real, personal-computer-worthy software packages that you can download (and use!) directly from an author's website. And all we need to do is agree upon a reasonably full-featured standard. (Oh crap...)
Then all that lib* stuff which did not make it into the current Standards Base gets statically linked-in (or otherwise physically included) by the application programmer who then assumes responsibility for the WHOLE package (especially distributing it).
Voila! Real, personal-computer-worthy software packages that you can download (and use!) directly from an author's website. And all we need to do is agree upon a reasonably full-featured standard. (Oh crap...)
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
re:repository culture
I don't think it would be much extra work for developers to provide two alternate downloads, one with everything except basic (LSB) libs, and one with just the basic app and no libs.
Look how easy it is to compile mplayer and xanim,who include what you need.
Now focussing on the immediate problem again, I did find a live CD called Develinux which provided instant development environment. I found though that it wasn't as usable as Kanotix for everyday tasks so I ended up ditching it and just installing what I needed to Kanotix.
So what I propose is:
1) Take a Kanotix iso and eliminate fluff (the lite iso is good base)
2) Add all dev packages needed for KDE development BUT AT SAME VERSION AS RUNTIME LIBS OF KANOTIX ISO so normal Kanotix users can actually benefit from your eventual programming gems
3) Even better, synchronize to the lowest common denominator of KDE versions in current Knoppix, LSB, etc...
4) Remaster iso and distribute this on your website so no one has to duplicate this task.
The solutions are there for the taking. Probably there is a better long-term solution, but this is ready now.
I don't think it would be much extra work for developers to provide two alternate downloads, one with everything except basic (LSB) libs, and one with just the basic app and no libs.
Look how easy it is to compile mplayer and xanim,who include what you need.
Now focussing on the immediate problem again, I did find a live CD called Develinux which provided instant development environment. I found though that it wasn't as usable as Kanotix for everyday tasks so I ended up ditching it and just installing what I needed to Kanotix.
So what I propose is:
1) Take a Kanotix iso and eliminate fluff (the lite iso is good base)
2) Add all dev packages needed for KDE development BUT AT SAME VERSION AS RUNTIME LIBS OF KANOTIX ISO so normal Kanotix users can actually benefit from your eventual programming gems
3) Even better, synchronize to the lowest common denominator of KDE versions in current Knoppix, LSB, etc...
4) Remaster iso and distribute this on your website so no one has to duplicate this task.
The solutions are there for the taking. Probably there is a better long-term solution, but this is ready now.
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
Write reply
This item is closed, it's not possible to add new comments to it or to vote on it
Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 391
06:03PM,
Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/globalfunctions.php on line 1112
Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/globalfunctions.php on line 1132
20/07/06