Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (475)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (530)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Linux == reduced life expectancy  (Read 1878 times)
0 Members and 1 Guest are viewing this topic.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Posted 2005-01-08 15:19:53 »

EDIT: some great good may come out of all this. Eventually I switched to using Courier-MTA as the email server, and ...it has a fully documented and fully configurable system for using arbitrary MySQL databases to provide all the authentication data. user@jgf.org email accounts appear to be very simple to provide...don't even have to change the DB (courier lets you use any schema)

Debian is the only linux distro which is safe enough to use in production.

Debian is the worst documented of all linux distros. Most of the docuementation is WRONG, and lots of really important stuff (like the one-line change you *have* to make to Bugzilla's conf after you install, the default of which is pretty much "disable_myself ==true") is UNDOCUMENTED.

I'm trying to configure a mailserver on a Debian system. 1 hour later, I STILL can't find the fricking documentation on the config for mailservers on debian.

Most docs say "run eximconfig". Eximconfig has been deleted from Debian as of over a year ago and has no replacement.

IF you try and manually edit exim conf, you discover they have f*cked it up and made their own propriteraty config system for this ONE piece of software.

If you try to use the Debian proprietary config system you find references to lots of variables which are debian specific and undocumented, but have the word "debconf" inside them.

Debconf is supposed to be used to configure all Debian programs. Weird. I'd never used it, never even heard of it. Why? Oh. That's right - there's NO DOCUMENTATION FOR IT.

I ran the manpages: "man debconf"

Brings up a 3-line file saying "see debconf(7)"

Debconf(7) doesn't exist. I tried on other debian machines - doesn't exist there either. Eventually...I discover another website that says debconf is documented at "debconf(Cool".

Doesn't exist either. Look it up yourself in your favourite manpages site - only debconf(1) exists, and it tells you the documentation is located in debconf(7) which I'm starting to think doesn't actually exist on this damn planet.

****ing ****-**** *** ****ers. As they say, I feel like "Punching them till my knuckles bleed". My only option appears to be to remove all email packages  from Debian entirely and then manually install (breaking the Debian packaging system) a copy of exim which has NOT been hacked by morons and so I can actually just use the real, standard, fully documented, extremely widely used exim.

The stress of this ridiculous farce must have taken a good few weeks off my life expectancy. So, be warned folks: debian is slowly killing you Tongue.
</rant>

Just don't even *try* to install and maintain an email server on Debian, that's my advice.

malloc will be first against the wall when the revolution comes...
Offline kevglass

JGO Kernel


Medals: 118
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #1 - Posted 2005-01-08 15:56:49 »

Crikey, this is close to belonging in the land of the trolls.

Kev

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #2 - Posted 2005-01-08 16:02:55 »

I thought it might spare someone some pain before they got started. Or just amuse those who are prone to schadenfreude...

malloc will be first against the wall when the revolution comes...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline JasonB

Junior Member





« Reply #3 - Posted 2005-01-08 20:35:21 »

Quote
Debian is the only linux distro which is safe enough to use in production.


Oh really?!  I do wish you'd told me this 4 or 5 years ago before we installed redhat in our production servers.  Excuse me while I phone up our sys admin team, get them to format our 10 or so servers running Fedora Core immediately and install Debian, since you obviously have so much experience in these matters. I'm sure they'll probably object.  After all, we've been running Redhat in prod for years without any hitches... but no, it's now obvious to me that we must've been wrong.


Tongue
Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #4 - Posted 2005-01-08 20:58:37 »

Yeah, sorry Blah but I don't agree with you either.  Our production Fedore Core Linux servers are fine, have been for years, and likely will be for years to come.

And as for the docs, you have to learn the "Linux way": if you want to use a Linux server for any mission-critical work, don't use the bundled apps!  Download a known unmodified version from the developers' website, install and configure.  Ignore the fact that you're "breaking the packaging system" - that's also irrelevant.  This way you have the developer's code, with the developer's documentation - and can likely get support on it... from the developers.

Concerning your missing file, 2 minutes and Google turns up "Bug#275768: debconf: debconf(7) man page missing", so they know about it and will likely fix it in time.  But that's irrelevant - Debian have modified the software, so you shouldn't be relying on it; get a fresh copy from the Exim developers.

Hellomynameis Charlie Dobbie.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #5 - Posted 2005-01-08 21:22:36 »

Quote


Oh really?!  I do wish you'd told me this 4 or 5 years ago before we installed redhat in our production servers.  Excuse me while I phone up our sys admin team, get them to format our 10 or so servers running Fedora Core


LOL. Sure it's a personal opinion, but it's based upon the bug in the linux kernel which means installing redhat packages can prevent you from recompiling your kernel. Last time I checked, the kernel sources haven't been changed, and RPM is still buggy, so you're still at risk of buggering your server. Been there, done that, not pleased. Debian doesn't prevent this, but it reduces the chances from "small" to "minute" by making it much much less likely you'll ever get a screwed RPM setup.

Every single RH I've run since RH 7 has, sooner or later, broken it's RPM database. The system will carry on functioning but, usually, you can no longer compile kernels.

Debian's superiority comes partly because it's better tested overall (RH testing has historically been really poor - their network installer was broken with the same 5 showstopper bugs for 3 successive releases (5, 6, 7) and still had one or two of them in 8! That was ridiculous) but mainly because it's packaging system is much less likely to break, both in small ways: the design (slightly better), the UI (much better) and in big ways, such as the base packages (much much better tested) - which make it much less likely to break.

I've admined 5+ different debian machines now for approx 12 months, a mixutre of workstations and servers, and no-one has managed to break the packaging system. We have had *one* bad package that had problems, none of them dangerous to the system, and we had to contact the authors and get them to fix their package. In the same time period with RH, I usually see 5+ bad packages on the server (of which one may be a seriously dangerous brokenness) and 15+ on the workstations (of which 3-5 are seriously bad).

I belive the BSD's packaging system is even safer but we can't use them on any of the machines because of problems with BSD itself being not linux, along with some major system-level bugs in the BSD's (for instance some very bad networking problems in each of them, which we unfortunately cannot live with).

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #6 - Posted 2005-01-08 21:34:21 »

Quote

And as for the docs, you have to learn the "Linux way": if you want to use a Linux server for any mission-critical work, don't use the bundled apps!


For production deployment, I simply don't have the time, manpower, and too much responsibility to avoid the packaging system. We need efficiently maintainable systems, and packaging saves a huge amount of time and effort when doing maintenance, backups, particular builds, etc. With a bigger budget for these systems, and 3-5 100% linux-maintenance personnel it woudl be the way to go. But it's always going to cost you money, forcing a significantly inflated busget on you Sad.

Quote

Concerning your missing file, 2 minutes and Google turns up "Bug#275768: debconf: debconf(7) man page missing", so they know about it and will


LOL. So...possibly the attitude one needs for D is "if anything goes wrong with debian, don't bother trying to fix it, search the debian bugs DB first". I've spent years getting into the habit of assuming that any linux admin problem wasn't a bug but a feature I just misunderstood, or a typo in some seemingly irrelevant field, or that you used the letter "t" inside a variable value and for silly reasons you weren't allowed to.

But my experiences are pointing me in this new direction.

Quote

Debian have modified the software, so you shouldn't be relying on it; get a fresh copy from the Exim developers.


Yup. I finally found the debconf author, who explained how to get at the docs. I read the docs, and they don't include an explanation of the magic DEBCONF variables that pepper the application config files (the "complete user's guide" turns out to be just a few pages long) so I'm completely giving up at this point. Those variables don't exist anywhere in any script on the system, so they must be internal logic from debconf, i.e. presumably you have to read the DEBCONF developer's guide, learn how to write applications using debconf, and only then are you allowed the knowledge of how to configure someone else's application. Just like the good old days of linux support mailing lists with responses like "if you have to ask that question you don't deserve to know the answer" Tongue.

Insult to injury: all the debian stuff for the previous version of exim works fine, and is NOT bastardized, because I've actually maintained exim3 stuff using Debian. But...exim3 is so out of date that the original developers don't touch it any more and, basically, if new security holes are found no-one's going to patch them. Ha. Debian + exim works fine, so long as you don't mind using a copy of exim so old it's dangerous (old/unsupported mailservers loaded onto a hosted server are something to fear, IME).

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #7 - Posted 2005-01-08 21:49:31 »

Quote
Download a known unmodified version from the developers' website, install and configure.


EDIT: below when I say "not possible" I really meant "not possible to remove the MTA". I was intending to have two MTA's sitting on the hard disk (debian forces you to) and one of them just delete it from all startup scripts. In the end, I decided to just install and use courier, since Debian haven't screwed up the config for that one Smiley.

I don't think it's possible. Sad. Debian won't let me. That "package system so great it prevents you from breaking your system so that you can't compile the kernel" is so good it's preventing me from breaking the system. I would cry, so I'm jsut going to laugh instead.

Unfortunately, lots of packages (any distro) have stupid crap like this in them. For instance:

- mysql server requires you to have an email-reading application
- the email applications all require an email server to be installed

Very hard to see why either of those are *requirements* hard-coded in and unavoidable. I actively do not want MySQL to *ever* read *any* email from *anywhere*. Equally, I don't want any email client on this *server only* machine that will *never* be configured to accept incoming emails and will *never* have anyone logging in to read system mailboxes.

Sigh. Sometimes just using linux feels like bashing your head against a wall made by the people who think that just because they like "cool features" those features must be forced upon the rest of the world - like the stereotypical linux user who visits your house and while you're getting them a cup of tea they're deleting telnet from your machine and replacing it with ssh (has actually happened to me, once).

The fact that telnet is essential to anyone doing network protocol testing (it's a TCP protocol testkit!) is something that you have to patiently explain to such people using words of no more than one syllable, preferably whilst they're sedated so they actually listen.

(tongue in cheek. Although I would probably go postal if someone just walked in and did this to one of my network dev workstations...)

EDIT: PS: Apologies for being a grump; this kind of crap just trying to do something trivial (get javamail API to work) has delayed JGF work by 5 days. In the first place I don't understand why Sun released an API for sending email that doesn't include a class that sends email (it only includes classes to login to someone else's mail server and upload emails), and my tolerance has been worn down by each blow since then. Sigh.

malloc will be first against the wall when the revolution comes...
Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #8 - Posted 2005-01-10 14:12:01 »

I have the perfect solution for this!

FreeBSD  Smiley

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #9 - Posted 2005-01-10 14:19:27 »

Quote
I have the perfect solution for this!

FreeBSD  Smiley

DP


Getting all the linux apps to run is too hard or too scary.

And the last I heard, the networking layer is buggered in most of the BSD's at the kernel level, using O(N) or worse algorithms for functions that are supposed to be O(1) (And are, in linux). Although, IIRC, FreeBSD has considerably better networking than the others, even the one supposed to be good at networking?

Just my little bit of FUD. But investigation gave me enough confidence that those might be accurate that I couldn't risk it.

malloc will be first against the wall when the revolution comes...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #10 - Posted 2005-01-10 14:38:51 »

no no noooo, FreeBSD 5.1 is the networking thing you were referring to. Its at 5.3 now (5.4 is the due stable release)

The networking of freebsd is the best i have ever seen. It has more drivers than all of the linux distros combined (over statement, but you get the gist).

I have never managed to get Samba to work on any linux distro, but it worked flawlessly in freebsd. I even managed to get it to bind with our ActiveDirectory server.

Its very neat, you should give it a shot on a test pc. If it doesn't impress u like debian does and more, I will get my head shaved and stick it on my monitor!  Grin

DP



Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #11 - Posted 2005-01-10 14:51:37 »

Quote

The networking of freebsd is the best i have ever seen. It has more drivers than all of the linux distros combined (over statement, but you get the gist).


Just to be clear: I couldn't care less about the drivers, it's the fundamental shared features, like how it manages readiness notifications, file-descriptors for connections, etc. How fast can it iterate across 5k connected channels and find those that are ready, how efficient is the kernel at pullign data out of the NIC buffer and into the application across all drivers (i.e. what's the kernel overhead etc).

Quote

I have never managed to get Samba to work on any linux distro, but it worked flawlessly in freebsd. I even managed to get it to bind with our ActiveDirectory server.


That's saying a lot Smiley. Then again, the real test of Samba is: can you mount the samba server as part of your root FS in linux, and then kill the server, without it screwing up all your cilent machines? The samba mount daemon stuff and kernel modules are FUBAR (just a pile of turd, really), so much so that IIRC the samba project disavows any involvement with the linux kernel module because it's so bad. Maybe that's been fixed by now in the linux kernels.

malloc will be first against the wall when the revolution comes...
Offline Jens

Senior Member




Java for games!


« Reply #12 - Posted 2005-01-10 15:23:40 »

Quote

IF you try and manually edit exim conf, you discover they have f*cked it up and made their own propriteraty config system for this ONE piece of software.

If you try to use the Debian proprietary config system you find references to lots of variables which are debian specific and undocumented, but have the word "debconf" inside them.

Debconf is supposed to be used to configure all Debian programs. Weird. I'd never used it, never even heard of it. Why? Oh. That's right - there's NO DOCUMENTATION FOR IT.


Well, debconf is the tool, which configures your packages. Were you never asked any question when you installed a package? You can reconfigure your package using "dpkg-reconfigure <package>", where <package> stands for the name of the package you want to reconfigure. If you want to reconfigure debconf itself, then you have to run "dpkg-reconfigure debconf". Debconf only does some basic configuration to make life easier. It does not stop you from editing the config files manually. Actually that's an advantage. If you want real help, then please ask in an appropriate mailing list / newsgroup like linux.debian.user (if the problem is really Debian specific).

Xith3D Getting Started Guide (PDF,HTML,Source)
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

ctomni231 (34 views)
2014-07-18 06:55:21

Zero Volt (30 views)
2014-07-17 23:47:54

danieldean (25 views)
2014-07-17 23:41:23

MustardPeter (27 views)
2014-07-16 23:30:00

Cero (42 views)
2014-07-16 00:42:17

Riven (44 views)
2014-07-14 18:02:53

OpenGLShaders (32 views)
2014-07-14 16:23:47

Riven (31 views)
2014-07-14 11:51:35

quew8 (30 views)
2014-07-13 13:57:52

SHC (66 views)
2014-07-12 17:50:04
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!