Slashdot Mirror

Let's say one of the telephoneNumber items is actually the front desk number in an office shared by a few dozen employees. Now let's say the number changes - you have to change that number in several dozen places.

True, but I would have tried to design the hierarchy to avoid that. To be more specific, refer to this .pdf (ps and an ugly jpeg also available). This is what I'm using for my directory format (I'm writing a perl Outlook .csv to .ldif convertor) -- Company-wide information goes under the company, and only the differences are put under the contact's BusinessContactInfo branch. There's only one place that needs changing there...

There's also the possibility of just using an LDIF modify command. I'm not really great at LDAP yet but I believe that it is possible to have the LDAP server walk the tree and modify the telephone number from (xxx) yyy-zzz to (aaa) bbb-ccc. Just because it's possible doesn't mean it's nice to do; walking the tree isn't something I'd like to ask the server to do on a daily basis, hence my attempt at organization.

The "joiner" table you refer to is hardly a "kludge". It is an accurate representation of the association between items.

I referred to it as a kludge because to get the benefit of a hierarchial database in a relational one, everything must be done in joiner tables. i.e. you have a table of names. Then a table of names and telephone numbers. Now a table of names and addresses. Don't forget the table of names and spouses. Or the table of names and contact categories. And so on and so on and so on. There's no longer any structure, just a bazillion tables all linking each other. Normalization bliss, perhaps, but a pain in the ass to work with.

aside: If anyone is interested, the utility will soon be done. The actual convertor is done, but now I'm trying to get the second portion to actually fill the LDAP directory "smartly" to avoid the types of problems brought up by flacco. i.e. when it adds a contact, check to see if the company is already there and if so, if the BusinessContactInfo is idential to the company's info. If so, strip it out. if not, try to figure out how to best add it) -- if anyone's interested in helping me make the directory design better or maybe just wants a copy of the csv-to-ldif script, let me know. I'm new to all this but I want to get my company's umpteen-thousand contacts out of Outlook-Only land.

aside 2: Does anyone know how to get ghostscript to spit out nice png or jpeg files from postscript input? ps2pdf works great for .pdf, but I can't seem to figure out how to turn on the anti-aliasing for png/jpeg.

Let's say one of the telephoneNumber items is actually the front desk number in an office shared by a few dozen employees. Now let's say the number changes - you have to change that number in several dozen places.

True, but I would have tried to design the hierarchy to avoid that. To be more specific, refer to this .pdf (ps and an ugly jpeg also available). This is what I'm using for my directory format (I'm writing a perl Outlook .csv to .ldif convertor) -- Company-wide information goes under the company, and only the differences are put under the contact's BusinessContactInfo branch. There's only one place that needs changing there...

There's also the possibility of just using an LDIF modify command. I'm not really great at LDAP yet but I believe that it is possible to have the LDAP server walk the tree and modify the telephone number from (xxx) yyy-zzz to (aaa) bbb-ccc. Just because it's possible doesn't mean it's nice to do; walking the tree isn't something I'd like to ask the server to do on a daily basis, hence my attempt at organization.

The "joiner" table you refer to is hardly a "kludge". It is an accurate representation of the association between items.

I referred to it as a kludge because to get the benefit of a hierarchial database in a relational one, everything must be done in joiner tables. i.e. you have a table of names. Then a table of names and telephone numbers. Now a table of names and addresses. Don't forget the table of names and spouses. Or the table of names and contact categories. And so on and so on and so on. There's no longer any structure, just a bazillion tables all linking each other. Normalization bliss, perhaps, but a pain in the ass to work with.

aside: If anyone is interested, the utility will soon be done. The actual convertor is done, but now I'm trying to get the second portion to actually fill the LDAP directory "smartly" to avoid the types of problems brought up by flacco. i.e. when it adds a contact, check to see if the company is already there and if so, if the BusinessContactInfo is idential to the company's info. If so, strip it out. if not, try to figure out how to best add it) -- if anyone's interested in helping me make the directory design better or maybe just wants a copy of the csv-to-ldif script, let me know. I'm new to all this but I want to get my company's umpteen-thousand contacts out of Outlook-Only land.

aside 2: Does anyone know how to get ghostscript to spit out nice png or jpeg files from postscript input? ps2pdf works great for .pdf, but I can't seem to figure out how to turn on the anti-aliasing for png/jpeg.

Let's say one of the telephoneNumber items is actually the front desk number in an office shared by a few dozen employees. Now let's say the number changes - you have to change that number in several dozen places.

True, but I would have tried to design the hierarchy to avoid that. To be more specific, refer to this .pdf (ps and an ugly jpeg also available). This is what I'm using for my directory format (I'm writing a perl Outlook .csv to .ldif convertor) -- Company-wide information goes under the company, and only the differences are put under the contact's BusinessContactInfo branch. There's only one place that needs changing there...

There's also the possibility of just using an LDIF modify command. I'm not really great at LDAP yet but I believe that it is possible to have the LDAP server walk the tree and modify the telephone number from (xxx) yyy-zzz to (aaa) bbb-ccc. Just because it's possible doesn't mean it's nice to do; walking the tree isn't something I'd like to ask the server to do on a daily basis, hence my attempt at organization.

The "joiner" table you refer to is hardly a "kludge". It is an accurate representation of the association between items.

I referred to it as a kludge because to get the benefit of a hierarchial database in a relational one, everything must be done in joiner tables. i.e. you have a table of names. Then a table of names and telephone numbers. Now a table of names and addresses. Don't forget the table of names and spouses. Or the table of names and contact categories. And so on and so on and so on. There's no longer any structure, just a bazillion tables all linking each other. Normalization bliss, perhaps, but a pain in the ass to work with.

aside: If anyone is interested, the utility will soon be done. The actual convertor is done, but now I'm trying to get the second portion to actually fill the LDAP directory "smartly" to avoid the types of problems brought up by flacco. i.e. when it adds a contact, check to see if the company is already there and if so, if the BusinessContactInfo is idential to the company's info. If so, strip it out. if not, try to figure out how to best add it) -- if anyone's interested in helping me make the directory design better or maybe just wants a copy of the csv-to-ldif script, let me know. I'm new to all this but I want to get my company's umpteen-thousand contacts out of Outlook-Only land.

aside 2: Does anyone know how to get ghostscript to spit out nice png or jpeg files from postscript input? ps2pdf works great for .pdf, but I can't seem to figure out how to turn on the anti-aliasing for png/jpeg.

but the second you want to do anything the least bit interesting the tool fights you every step of the way.

I refuse to stop doing interesting things in my programs, so until these tools stop fighting me I won't use them.

Can you give some specific examples? I'm no app programmer but last year I was called in to turn around a wholly-mismanaged software project. It's there I learned about Borland C++ Builder.

Now, I generally dislike app programming -- I am an embedded systems designer by trade -- but I can learn very quickly and seem to have a sense of how a user interface should work, hence my involvement in this project.

Anyway, I learned the basics of C++ (I'm a fluent C/asm [many platforms] programmer), DCOM and Borland's VCL in a few weeks and managed to get this project turned around and at least releasing stable, usable releases. But when learning to use C++ Builder I occassionally butted heads with it with respect to form design and so on but it was because of my lack of experience with the software, not the software itself, which was the cause.

Examples: tabbed forms. You actually use the tabs in the form designer to switch to another "pane" and put objects on it. That seemed weird to me -- You literally stacked form elements on top of the correct pane, swapped panes and continued stacking. Neat trick, but in my mind it wasn't "right". Raised panes worked the same way. I would have done it with some kind of selector but the end result is that C++B wasn't restricting what I wanted to do; it just wanted me to do it differently. I could have hit F12 and typed out the information and have it appear that way if I wanted as well.

Generally speaking, if you are trying to do "cool" stuff in your UI or your GUI forms designer is making your life rough, you are probably breaking the UI rules for the platform you're working for. Palm has some very strict rules but after working with it for a while you learn how it should be done to work and play "nice" with the user.

I've created my own KB already: http://www.mixdown.org/kb. This was done quite a while ago in PHP as a learning lesson and I've been itching for quite some time to finish it up. Three kids, a full time job and a couple of contract jobs make time scarce though. :-)

What the vision is:

• Full text entry (including accepting HTML and code)
• Adding graphics to the entries
• auto-keywording (basically eliminate all common words and phrases, the rest is keywords)
• manual keywording
• auto-rating (searches turn up entries, if the user clicks on the entry the link between the keywords used in the search and the entry retrieved is nudged up so that entry will rate higher next time)
• admin and peer rating - the traditional "was this useful to you?" type of rating
• supersceeding of entries - you can't eliminate an entry. If you want to make a change you can change it but the original entry is kept and marked as "supersceeded". Searches turn up the new entry but link to the old one as well. That way you build up not only knowledge but also "how not to do it" knowledge which is very important.
• Entry linking - Kind of like E2 but with a datastore a little more connected. :-)

I've got the text entry and bits and pieces of the keywording and rating working. I'll be redoing it in Perl and finishing it up When I Get Time<tm> -- the current source is available to anyone if they want. As you can see if you go and look, I use it as a place to store things I have learned the hard way or found interesting and know I won't be able to find again.

This isn't directly related to business KBs but I figure this type of system would work most excellently in a customer-service and engineering environment.

Here is my current "general" resume. It fits into two pages but remains fairly general. I have a broad range of interests and abilities and I had the same problem you did... Polished it up and boom... 3 pages.

What I ended up doing was keeping the actual job details kind of skimpy and putting my abilities and experiences up top. I also dropped off a few older jobs which didn't really show too much.

Lastly, I stuck on some keywords at the very bottom to help bots find the right resume. I get about two to three requests a week for more info so I think it seems to be working alright. :-)

When I get a request for more info they usually ask for the resume in Word .doc format. What I do then is adjust the resume to target the job more specifically.

A database backend is incredible overkill for something like this.

I'd generally agree with you on this, but then I look at my own system and disagree.

I run PostgreSQL which is neither here nor there in this discussion, but the point I am trying to get back to making is that yes it's silly to use a fancy DB system for something like this but when you then also realize that I use the same DB to store more than that. I store info from my knowledgebase, vehicle maintenance log, family journals, MP3 database and a variety of other small projects within various tables on the same database system. The advantage starts to become clear when you realize that a single perl module (DBI::Pg) gets me access to any of this data and it's all (hopefully) stored in an efficent manner. I don't have to worry about parsing the text files differently or doing anything special to back them up. When you start to use the same DB system for more than one project the benefits of storing even silly little things in a DB start to show.

It's late, but I think it's kind of like realizing that 16k cluster sizes on the old FAT16 systems becomes much less hassle than when you partition and format to keep nice 4k or smaller clusters but then need 400M of room only to find that you ahve 50 here, 100 there, 75 somewhere else, etc... I long ago became bored of that and now use a nice LVM. I don't ever have to worry about running out of room or having to make a /usr1, /usr2, /usr3, etc. Same kind of thing with the database way of storing things that really don't need it.

Actually yes I do... I run a modified version of iplog (check freshmeat) and my system logs get simulcast to another server with no other functions save for sending email out. I imagine I could make it even more secure by sending the logs to it via a serial port (entry in my knowledgebase about this) or using a 2nd network card in the server but this suffices for now and allows me to have several servers send logs to the same log box.

Every night I have a cron which greps the shit out of the log and what's left is anything unusual. (90000+ lines in 24-hour period usually drops to about 150 lines when I'm done grepping the normal stuff out) I review that every day. I also have other cron jobs which page me if my 5min load is over 5, my disk space gets too low or if there are more than 6 people logged in.

I also am working with a friend on a modified patch to Bash (the original is on the same page as iplog) which drops the connection if it's being executed as root and the terminal is not a (v)tty. Hoping to add functionality where it also sets up a -j DROP in ipmasq and mails me on it too.

Finally, there are other security measures in place like md5summing critical parts of the system before the backup, not allowing telnet or root/empty password ssh and such and so forth.

Paranoid? Yes. But then again that's what I'm paid to be.

One fact which all the search engines must realize, as well as cache companies like Inktomi and Akamai, is that the Internet is becoming increasingly dynamically-generated, personalized, and transactional -- exactly the kind of content least suited for static spider-driven search engines and static cache technology.

That's where I think it would be a great idea to embed the spiders within people's browsers for this distributed search engine project. Of course you'd need to be able to set up a system to selectively not spider sites / pages (account info, etc.) but the idea is as you're accessing the info in the web database the HTML that pours out gets indexed and then sent to your upstream. A lot of database information stays put or changes very little, but it's hidden behind a search or an index of some kind (see my knowledgebase for an example). If you embedded the spider within the browser, you'd get the content without hammering sites and all is good.

I would have to question Linux on any gaming console. I want the gaming console running something that I don't know the name of, and don't care to, because it means it's so proprietary, it will work wonders with the proprietary hardware it runs on.

Actually the documentation on the N64 is quite extensive (for a proprietary system). And with all that fancy-do hardware you could write one hell of an accellerated X server. Think of it. Throw in a cart that has a 100bT port on it, plug in a keyboard (the controller interface is not too difficult to hack) and you have a cheap, fast X terminal for web browsing / gaming. Insert kiosk / cafe / whatever use here.

I wish I had the link, but I've already seen X on an N64.

And why's this guy taking everything apart to learn? dextrose has compilers, assemblers, disassemblers and all manner of documentation on programming this fscker.

Get yourself a Doctor V64 or, what I use, a Z64 and start programming. I like the latter because it's smaller, doesn't use CDs or take up a parallel port and (upon taking it apart) is an embedded 386. The V64 is a 6809 (IIRC) machine with a lot more custom circuitry.

My goal for it is to hook up a network card to it's internal PC/104 slot and get rid of the need for a Zip drive altogether. Boot via BOOTP, grab games from my server via TFTP. The source for the BIOS is available on the 'net and all it is ATM just OpenDOS with some custom executable to run the embedded PC <-- N64 part.

There's no need for custom hardware. Hell a simple ROM emulator would work. There *are* tricks to doing it in hardware (they have a lock chip on each cart IIRC) but if you got one of those V64jr units you could hack it and put a ROM emulator on that if you *really* felt you needed to. (the V64jr lets you read/write to its onboard memory with a parallel port so a ROM emulator is not necessary, but most good ROM emulators let you have breakpoints and other good things for development). From what this guy's website said, he was using custom hardware to read/write to N64 memory. Waste of time / energy / effort! Proprietary interface!

My brother already programs for the N64 (just simple stuff but his time is limited too :-) -- All you're doing is writing a ROM image. You do *not* need to rip the thing apart to run Linux on the pig. All the info (hell you can even get detalled info / memory maps / etc on the hardware) is available from dextrose or #n64dev on efnet. All this scope tracing / etc is bullshit if you want to really program it / port Linux to it.

Mind you now, if he was the curious sort like myself, he'd have done it just for fun. :-)

... in the gbdev mailing list. I run the archive at mixdown.org/gbdev.

The add-on would be a DSP or fast processor because, as one poster correctly put it, the GB processor (a bitched-up Z80) simply does not have the balls to decode an MP3 stream at any usable rate.

I too consider a GB MP3 device totally useless. A RIO gives you all that, has more memory (IIRC) and is better on batteries, to boot. The GB can't even be used as a (proper) audio output because there is only a single pin on the GB cartridge you can inject audio on, so that leaves stero operation out. Unless they've somehow used the GB sound chip in its digitized mode.

The people in that list have a lot of great ideas, but some seem to want to push the platform too far (read: beyond something economically worthwhile). Things like MP3 addons, PDA software, raycasted 3D graphics and <cough> a multitasking OS are, IMHO, a waste of effort and brainpower for otherwise bright minds. However... full-colour imagery, robotics and a multitude of cheap computing projects are well worth the effort.

If you've got one and you want to hack it, join up. You can buy Bung's cartridge to transfer your software to a real GB or use one designed by one of the list gurus. There are some people in there who do GB code for a living, others who are under Nintendo NDAs, and even others who seem to know more than Nintendo themselves knows about the GB. :-)

Just be something can be written to once easily doesn't mean it can be changed easily. The serial number is probably stored on a PROM. You'd have to purchase that exact chip, read the information from the old PROM, change the serial number, write the new PROM, desolder the old chip, and solder in the new chip.

oh PUH-LEESE...

it is NOT difficult to do. first off, custom silicon isn't cheap, even in the thousands or tens of thousands. Most mask ROM or ASIC plants won't look at you till you hit a hundred thousand or more. So that leaves tradiditional write-once memories which are easy to obtain. But anyway back to the post at hand:

Desoldering and soldering is simple. Even at the SMT level and yes I know what I'm talking about. I used to hand-solder 204-pin PQFPs and 68-pin TQFP packages by hand. Hell, look at cell phones: YES a PROM would be the best solution, but what'd they do? EEPROM or Flash. Instant reprogramm-o. I have a neat little trick at mixdown which describes how to pick off ESN/MIN pairs from the air because they decided to use reprogrammable technology for the "unchangeable" ESN/MIN.

Look at it this way: if you put another chip on the board, you've all of a sudden added cost and space. And I/O that you didn't need before (think I2C here). So they put the codes in the Flash, or, if they already have some kind of nonvoltatile storage for parameters, E2PROM since Joe Computer user doesn't care or can't modify it.

Don't spew off this "oh muh GAWD you gotta desolder an' solder an' it's custom and oh muh GAWD!" If you wanna counterfeit you're not afraid of this. And most Joe Computer users who are concerned with privacy have a hacker friend around who isn't afraid of his soldering iron.

The security is better in unix, but its nowhere near insurmountable. Once a user is compromised, even through their own stupidity, its very possible to wreak havoc outside of the scope of that users account. Even disregarding the potential of denial of service attacks a bored script kiddie could implement a number of scripts from rootshell.org.

Not entirely true. On mixdown we've had many attempts from outside but nothing has gotten through. So much for rootshell. What they read there I also do and patch it up if necessary. Rootshell sells to both sides of the war. :-)

As far as internal security, I was tempted to set up a test/test account on the system and let you guys have at it but I want to do a double-check on our permissions first. From the outside, it has no known exploits. From the inside, I've set up fairly tight ulimit regulations, including CPU time of 5 seconds and and data size of (I think) 8 megs. That keeps any rootshell surfing script kiddies from keeping it bogged down for long. I get paged if the number of users grows above a set limit and also if the box 15min load goes above 5. Internal security is much harder to imlement than external security.

Anyway that's my take on it. Unix-style security may not be infalliable but it is a lot better than the WinDOS "a root for every user" methodology.

There is another thread around here about how these virii would exist in a Unix environment as well since they're spread through email. This is true, but you would not achieve the same level of destruction unless you read your mail as root. I also don't know of any hooks in Pine which would cause it to automagically run my email attachments. :-)

Start with the basics: remove any modules you are NOT using. Be careful with your CGI useage. Make sure they don't get executed anywhere any user can write to.

Use ipchains to deny incoming packets that come in from outside interfaces with local network IPs. That includes denying traffic from your IP when it comes in from eth0. Block all the "private" ips (10.0.0.0/8, 192.168.0.0/16, etc.) which are coming in on outside IPs. That will stop most spoofs which rely on your system trusting itself dead in their tracks.

I run my little knowledgebase at mixdown.org and while the knowledgebase itself is not secure (anyone can read, write and edit articles), I feel the underlying system is quite secure. When I get the database stuff more functional, I'll tighten up access.

I'd appreciate anyone who finds holes to mail me. Also, if you want to screw around with the database a little, go ahead. :-)

Andrew

Start with the basics: remove any modules you are NOT using. Be careful with your CGI useage. Make sure they don't get executed anywhere any user can write to.

Use ipchains to deny incoming packets that come in from outside interfaces with local network IPs. That includes denying traffic from your IP when it comes in from eth0. Block all the "private" ips (10.0.0.0/8, 192.168.0.0/16, etc.) which are coming in on outside IPs. That will stop most spoofs which rely on your system trusting itself dead in their tracks.

I run my little knowledgebase at mixdown.org and while the knowledgebase itself is not secure (anyone can read, write and edit articles), I feel the underlying system is quite secure. When I get the database stuff more functional, I'll tighten up access.

I'd appreciate anyone who finds holes to mail me. Also, if you want to screw around with the database a little, go ahead. :-)

Andrew