How did companies manage before call centres were commonplace?
Simple, they had a thing called a helpdesk. The person who answered the damned call helped you. They didn't write down everything you said and hand you off to someone else to explain your problem all over again. They were on the phone with you until your problem was fixed or they had an answer for you. I remember being part of a 4 HOUR call trying to figure out why this guy's modem wouldn't stay connected -- I was even on the phone with two Carolina Telephone (Sprint) techs at two COs trying to figure out who was tearing down the call. (We signed him up with a different ISP.)
(For CT's part, that was the first PRI they had ever installed -- EVER. I think they bribed a BellSouth tech to get it setup correctly -- I remember hearing someone laughing histerically in the background shortly before it synced up.)
First, no one will sign that NDA. I never signed mine at the CP&L owned Interpath Communications -- Capitol Broadcasting never asked us to sign one. (They tried to sneek it into the employee handbook, but I refused to sign that either.) I wasn't the only one who refused to sign it.
As for everyone being a supervisor, they are just giving their customers what they want. They always ask to speek to a supervisor, so just make everyone a supervisor.
Years ago, I (not techsupport but network ENGINEERING) got a call from some frantic woman. She was an AOL user... she called the NOC line at Interpath -- which requires a "magic number" to get my phone to ring.
"This is not AOL, ma'am. There isn't a [censored] thing I can do for you."
Ahh, the memories... I (and some of us other non-helpdesk peoples) used to sit in the back of the fishtank (helpdesk call center) and heckle helpdesk (and the callers.) [I miss those days.]
What you've described isn't a complete picture. Were the on campus phones connected to the "miniswitch"? Was the Prez's phone connected to the CLEC switch or the University's miniswitch? (I can already answer part of that... he wasn't connected to any CLEC unless it's a "business class" line. 911 rules usually kill any CLECs chances of selling residential service.)
What seems most plausable is the phone being connected to the university phone system (miniswitch, PBX, or more likely a multiplexor.) And that system being heavily overtaxed to the point of not noticing the off-hook event -- I've seen analog PBXs do that. I've been in this kind of telco environment at college (NCSU.) The way the system at NCSU was 8 years ago, if everyone in Bragaw picked up their phone (800+ phones), some of them would not get a dialtone; the multiplexor in the boiler room bridging the phones to the fiber switch in Lee did not have the capacity. (Voice barely worked and modems were a lost cause.)
Because CLECs sell channel services instead of bandwidth. It's like buying a POTS phone line... the telco is "required" to have the switch capacity to handle every line. (That only means you get dialtone from the switch everytime you pick up the phone. Interswitch capacity can and does cause failures -- "all circuits in use".)
No where have I seen anything to suggest Cogent is promising 100Mbps from any point in their network to all other points in their network. Your router to their switch is 100Mbps. That's about it. (QoS isn't free. In fact, it's one hell of a revenue generator.)
I knew someone was going to force me to give this long and generally cryptic description...
Where I work, we use Rational Clearcase for version control (etc.) Unlike conventional builds, the only explicit dependancies that must be listed in the Makefile (which is, itself, under version control) are critical elements outside clearcase. Clearcase audits builds to construct configuration records enumerating what was done to create an object (called a derived object.) That includes every clearcase file referenced, the commands executed ("build script"), and environment variables referenced. Clearcase evaluates that information to see if it needs to rebuild it (or "wink-in" a copy someone has built -- use their copy instead of compiling it yourself.) That works perfectly with any sane langauge.
HOWEVER, with java, that's a nightmare. Allow me to demonstrate the complexity of the problem which you you seem to have ignored. When you run javac, it will recursively compile everything it needs. It will not verify the up-to-dateness of class files. If foo.java requires elements from bar, it's only going to look for bar.class. If it exists, it uses it - period. It will not look for a source file or try to rebuild it. If bar.class isn't available, thenjavac will build it in the process of building foo.class.
In the realm of clearcase, this creates a very serious problem. Let's say you have two java source files: foo.java, and bar.java. In the Makefile, they are entered such that they will be built in that order. If foo requires elements of bar, then the first time javac is invoked, you'll end up with foo.class and bar.class and configuration records showing the coresponding java source files were referenced. Then the build system will see bar.class exists and evaluate it's CR. It's build script won't match and thus gets rebuilt. If you run clearmake again -- having changed nothing, foo.class will get recompiled because bar.class is now different.
The problem is that java source is compiled from java object code. The result is an impossible nightmare for build and configuration management. No one can list every damned dependancy for everything in the Makefile. You cannot carefully order things in the Makefile to control the compile sequence (so bar is always evaluated before foo, etc.) Even if you did manage to build the dependancies into the Makefileand maintain them everytime a line of code changes (never gonna happen), you'll still end up with overlaped, circular dependancies; foo depends on bar who depends on baz who, in turn, depends on foo (I trust you can see the mess; one of them will always be out-of-date.) Suddenly you have to put special rules and targets in the Makefile to deal with clusters of source files.
You are correct in stating javac is not a compiler in the normal meaning. However, without 3rd party products, that's all one has to compile java source into java bytecode. So, there are very few options... You can go the complex route and wire everything into the Makefile and watch the source and compilations closely for the rest of eternity (read: pray.) You can take the shutgun approach and rebuild everything when any source file changes -- part of the build already does this, but I don't like it. Or find a 3rd party tool to hide part of the complexity.
Right now (if I could get the developers to make up their mind and stick with one JDK and one IDE) I'm building everything with JBuilder's bmj tool. It's not perfection, but it's at least consistant (mostly.) Even with bmj, I still have problems with overlapped dependancies -- one package depends on another or projects building on each other. Right now, the source tree for this development is rather small, but it's growing and will continue to grow -- there's 1.4G of C++ source, how much java source are we going to have in a few years? (I don't want to think about it.)
As for serving up a web site, servlets and JSP are compiled down to bytecode, and unless your perl or PHP script has been compiled down, that Java bytecode is going to run *plenty* fast.
And that's one of my problems with JAVA... damned bytecode. Everyone moved away from BASIC because it's a tokenized, and therefore interpreted, language. This's nothing different in java bytecode, but everyone fsckin' loves java for it. It's all still binary instructions for a nonexistant processor. (Ok, Sun did try to push a java (co)processor, but it flopped.)
JAVA as a pure programming language is, more or less, C++. [C++ for people who shouldn't be programming in the first place, IMO. Maybe I taught FORTRAN labs a little too long.] The only real difference is the lack of header files to define data structures -- java gathers everything from the object code. That, in itself, is both an interesting feature and a major, major nightmare for build and configuration management (something I'm paid to do.)
To be fair, a java servlet is the same thing as compiling a C/C++ CGI into the web server. BTW, you can do that for apache and a few windows web servers. (apache DSO's and windows DLLs)
It doesn't mess with horizontal anything -- and certainly has nothing to do with timing.
Macrovision places a superwhite ("high voltage" as far as a video signal is concerned), high freqency pulse in the virtical blanking interval (VBI.) The pulse is designed to confuse the gain control circuits (the AGC - Automatic Gain Control) within the VCR. AGCs in TVs are slower to account for transient noise in the broadcast signal (modern TVs have macrovision "hardened" AGCs). VCRs are trying to record the signal so they have to adjust rapidly -- 30% too many electrons ("over white") fired at a phosphor pixel doesn't nothing; 30% too much voltage on a VCR R/W head is a magnetic disaster.
Things have changed since Macrovision was developed. Now, everything understands it and knows what to do with it. For example, the TiVo knows when Macrovision is present in the input video and (theoretically) stores that in the mpeg data to know to enable it when it plays it back. Almost all video codecs now support detection and reporting of Macrovision. Two of my VCRs don't care about macrovision at all -- they record is along with everything else without distortion.
I use the phrase "H-Card" so I'm a DSS pirate? First off, I don't have DSS (or cable:() None of my friends with DSS are stealing it -- even those who have H-card based hardware.
As for my point... the user interface, I've never liked the RCA crap -- it's slow and feels cluttered. And I don't like the new Sony's -- the interface is ugly compared to the original DSS receiver (yes, it's h-card based. that's all there was then) and much slower.
The ReplayTV's UI looks too much like a Ted Turner colorized TV Guide. The Tivo tends to waste screen realestate, but it's very easy to read.
The older ReplayTV's do have a firewire port. That hardware isn't free so someone, somewhere obviously had some plans for it. Archival might not have been one of them, however. It's more likely it would have been for attaching a digital camcorder. It doesn't matter anyway as the current units no longer have the firewire port.
I'm the one who's supposed to be embarassed? Leto asked and I answered. Did you ever see the old nugget-stats? The bwilson-stats isn't significantly different.
DCTI has had problems with stats for years and years. There were problems with statsbox being heavily overworked back in March/April of '97 when I first became aware of d.net. Problems have remained to the present -- insufficient processing power, too little drive space, missing logs, incorrect processing, database corruption, intermittent instabilities ("nothing changed, but it failed today."), etc. One would think after three years someone would have shoved a clue up DCTI's ass; I, at least, tried -- it sat on foobar for months and nugget never lifted a finger to even look at it (it's still there, btw.)
I know it's a volunteer effort (or was), but come on, this isn't quantum physics. If the keymaster or proxy network were handled in the same manner as stats has been, d.net would never have gone anywhere. Of course, the bottom line is that Nugget had nothing to do with the design of the proxy network.
Having looked through the cvs tree, I wouldn't say it was "revamped... completely." There may be conciderable redesign of the table structure and interaction ("schema"), but the system still uses the same basic design. The most time consuming part of stats processing is the initial tabulation. The fact that it's spread out over the day -- when everything is running properly -- without disabling access doesn't make much difference.
DCTI is still decompressing logfiles in place:
open GZIP, "gzip -dv $workdir$basefn 2>/dev/stdout |";
And copying the result into the database:
open BCP, "bcp import_bcp in $finalfn... -c -t, 2>/dev/stderr |";
At least, integrate.sql uses a running total instead of Nugget's original summation to the beginning of time method. There are still significant issues to be dealt with that DCTI hasn't suggested they're even aware of. (Just how big are the tables? How fast are they growing?)
[Note: It's actually less efficient now... logmod_rc5.pl reads the entire decompressed logfile and spits it back out with a 4-digit year and project code. Gez, that's a 5 second modification to the proxy source.]
The RF box physically supports this, but the TiVo UI doesn't have anyway of activating it. (Note: the TiVo powers up in pass-thru mode. That's why the "loading" screen isn't shown on the TV out.)
And yes, that's a serious pain in the ass when you have an antenna to aim with a two second display delay.
IMO, both user interfaces suck. I hate the way ReplayTV tries to pack too much onto the screen (and that color scheme doesn't help.) The TiVo wastes half the bloody screen. If you've ever used one of the old (H-card based) Sony DSS units, that's the kind of interface these things need -- that's a very good use of screen space.
ReplayTV could certainly have crushed TiVo... their older units have a firewire (usb?) port that could have been used for digital archival -- something no current TiVo can ever do.
How could dnet [stuff]/reduce/ your interest in them?
Many people will see this as DCTI "selling out". DCTI was formed by a losenit group of people in their spare time, as a hobbie. There was never any commercial intent. It was completely volunteer. No one was paid for anything; they did it because they wanted to. It was something "cool" to take up one's time. The spirit and ethic onwhich DCTI was founded has been betrayed. Maybe this is/was inevitable.
"new stats server"? When is DCTI going to stop throwing hardware (by translation, money) at badly designed processing?! The daily stats run can be done in minutes, not hours, and not require gigs of temporary database space. Two+ years ago I volunteered to assist in speeding up stats as the poor little dual pentium was dripping blood for hours everyday running the RC5 update. I screamed when I saw how things were done -- in nugget's words, it was designed to run, not run fast. I wrote a logfile processor to handle the tabulation of the keymaster's log files. The initial tabulation is what took 3-4 hours -- ungzip, BCP, sql query to tabulate. Factor in the size of the dataset (much larger than RAM) and how many times it was read from and written to disk and you can see what those hours were spent doing. The processor did the equiv. work in under five (5) minutes; plus the dbm hash storing the tabulation is additive (process each logfile as it comes in from keymaster) and perl compatible. However, nugget never looked at it; it went with me when I left. The process can be sped up even more...
You can read can't you? I'm "cramer" not "cowie" and I've not been in #distributed for a very long time. And I've not been on EFNet for a few months -- I have more important things to do than hunt for a server.
As for bitter... nah. What reasons do I have for being bitter? (with this commercialization, I guess I have one more.)
You bring up an interesting point. DCTI, as you have enumerated, has four "core" technologies: RC5, DES, CSC, and OGR. The RC5 stuff started out as genx and eventually became what is now DCTI. (It wasn't DCTI until sometime after genx folded. It was Distributed Computer Processing, or something like that prior to incorporation.) RC5-56 and RC5-64 are the same core. The switch from 56 to 64 was lightning fast -- on the order of days.
DES. To the best of my recollection -- and I was part of d.net then -- no one within DCTI wrote, from scratch, on their own, a DES core. Everything started out with brydDES and a generic "C" core. Later a "bit slicing" core was provided that made a significant difference to some platforms (most notablly, the Alpha.)
CSC. An interesting if little known factoid... It took DCTI an excessively long time to include CSC capabilities to the clients despite having had the source for a CSC core for months. And they later announced they would not be optimizing their CSC core -- translation: they are going to take what they were handed and run. (As I was told, the C code core came from Remi.)
OGR. This was my first "official" involvement with DCTI which eventually brought me into the inner circle (#dcti and the cursed "+o".) I took gasrp (garsp32 as I recall) and made it "core-able" which is to say it could be started and stop from any arbitrary point (well, at a clean stubing point anyway.) That was in late '97 -- the OGR-21 era. It took almost two (2) years and incorporating Greg Hewgill and the entire Golumb Ruler project to begin processing OGR. Granted, it's a different beast, but it shouldn't have taken that long.
DCTI used to be vary good at giving credit where credit is due. However, looking at the current credits page, they seem to have aquired a very selective memory. The only place you find my name is in the ledger despite over a year of contributions as a general coder, porter/builder, proxy op, and even keymaster briefly. (One of the NICs got fried. The new motherboard was never used because nugget refused to replace a dual Pentium 200 (233?) with a single but dual capable PII 300. Nugget's rant about SPS to MPS is bull... you can install NT as MPS on a single processor system and then stick a second processor in there later. It's one of the first questions asked during installation -- video card, keyboard, system type. But I'm not bitter.)
If you've ever watched any of the shopping channels, enormous collections of things tend to appear out of nowhere every few months. I especially like seeing them sell the same "we've only got twenty in the warehouse"/while they last swords every week.
(BTW, I've got several TiVo's so I'll never be bored enough to let that crap stay on my TV. In fact, my tivo's don't even know channel 30 exists.)
If you wanna be famous, perform a differential crypto-analysis of a series of buffer files. When you stop laughing, publish your results (and thus how DCTI's client communications are scrambled.)
You could do the same thing by disassembling the client, but what would be the fun in that? Besides, DCTI might (correction: would) send a legion of lawyers after you.
I'm amazed that no one has "broken" the encryption. Especially seeing how many hacked clients there have been -- I guess NOP's are faster to insert.
Since when is United Devices "a big company"? In most respects, DCTI is a bigger "company". UD's site does give many details about it's formation. They recently received their 13M$ in funding and sucked in high profile people (SETI@Home and D.Net.) How many people knew about/of United Devices prior to today?
From what I gather, this has been in the works for some time now. (Maybe not UD, but some form of commercial direction.)
Not necessarily. Database design is one of a very few true black arts (read: serious voodoo.) The number of queries alone isn't a problem. The layout of the data, indexing, number of queries, complexity of queries, and the volume of returned data all factor in.
Let me provide a real world example. Some years ago, it was my task to roll out RADIUS for an ISP's dialup network. The stock setup for the USR RADIUS server -- it was the only one I could get to talk to a SecurID server correctly -- was, shall we say, non-optimal. USR's stats said one (1) authenication per second when using postgres. Let's ignore the way they had postgres setup (fsync enabled) for the moment. The reason everything was so bloody slow was the database schema. Even though there was only 1 query against the USERS table, it had to return 5k. Each row of the USERS table contained everything you could ever imagine (well, that USR could imagine.) Each row consumed almost 5k of space.
After three months of testing, data collection, and analysis, I redesigned the mess. USR literally laughed at my design because it made between three and six queries depending on the user. They stopped laughing when I showed one of their engineers the setup actively handling over 100 authentications per second. The USERS table, holding 10,000 entries, was about 2M.
As I recall, postgres is designed (optimized) for a PPro. In my testing of postgres (it was the only DB the RADIUS application knew how to talk to), a 486DX50 was faster than a 533 Alpha -- running 6.2.1 (as you can see, that was a while back.) I've not done any tests since "time travel" was removed -- and boy did that make a difference.
Too be fair, let's remember postgres and mysql were both designed completely differently by different people for completely different tasks. Each does what the creators see as necessary.
And, for the record, MySQL does has transactional capabilities -- I'm really surprised no one has posted this. There was a press release some months ago about this complete with instructions on how to activate support for transaction when building. (Note: I've not tried it.)
And while we're comparing databases, why not compare against some commercial engines like Sybase and/or Oracle? I know Oracle will shit kitten, but do it anyway.
"Political program[s]"??? Gez. Don't bother wasting your time trying to teach these kinds of people how to live in society. Weither they are 10 or 30, they should have learned this kind of anti-social behavior is inrolerable. They should have learned that when they were 5. All that matters to them is their own tiny, insignificant piece of the world. Someone wrongs them (as they see it) so they strike back at the entire world. If their parents had taken a few seconds of their lives to actually participate in the upbringing of their children, maybe we wouldn't have so many mentally unstable people. "Spare the rod; spoil the child."
There's little point in investing the time (and my tax dollars) in civilizing the uncivilized. We spend enough on rehabilitating criminals who go out to commit more crimes. And while jail time does correct some, it's statistically worthless.
(I think it's time for another flood. Oh, wait, He promised never to do that again.)
Therein lies the problem: it takes NO experience to be an asshole or a script kiddie. (To some, being an ass comes natural.)
According to some articles I've read (sorry, no links), there are comparably few "hackers" and hundreds of "idiot" script kiddies who take the knowledge and (hard) work of the real hacker to do their childish shit. You've obviously never heard of a "rootkit" or a "DoS kit". They aren't entirely to the level of click here to break in but they don't require any "hacker" skills.
Personally, I think the Ido (ST:TNG) had a good idea... "There is only one punishment for breaking any law: Death." People (and I use the term loosely) perpetrating such things are more than proving their inablity to live and participate in a civilized society. I say treat them accordingly. If you had a dog that constantly ate the funiture, crapped in the middle of the living room, and pissed on the china, you would not tolerate it. It would be punished, exiled, banished, and/or executed.
Slashdot Mirror
- How did companies manage before call centres were commonplace?
Simple, they had a thing called a helpdesk. The person who answered the damned call helped you. They didn't write down everything you said and hand you off to someone else to explain your problem all over again. They were on the phone with you until your problem was fixed or they had an answer for you. I remember being part of a 4 HOUR call trying to figure out why this guy's modem wouldn't stay connected -- I was even on the phone with two Carolina Telephone (Sprint) techs at two COs trying to figure out who was tearing down the call. (We signed him up with a different ISP.)(For CT's part, that was the first PRI they had ever installed -- EVER. I think they bribed a BellSouth tech to get it setup correctly -- I remember hearing someone laughing histerically in the background shortly before it synced up.)
First, no one will sign that NDA. I never signed mine at the CP&L owned Interpath Communications -- Capitol Broadcasting never asked us to sign one. (They tried to sneek it into the employee handbook, but I refused to sign that either.) I wasn't the only one who refused to sign it.
As for everyone being a supervisor, they are just giving their customers what they want. They always ask to speek to a supervisor, so just make everyone a supervisor.
Years ago, I (not techsupport but network ENGINEERING) got a call from some frantic woman. She was an AOL user... she called the NOC line at Interpath -- which requires a "magic number" to get my phone to ring.
"This is not AOL, ma'am. There isn't a [censored] thing I can do for you."
Ahh, the memories... I (and some of us other non-helpdesk peoples) used to sit in the back of the fishtank (helpdesk call center) and heckle helpdesk (and the callers.) [I miss those days.]
- This isn't necessarily true.
What you've described isn't a complete picture. Were the on campus phones connected to the "miniswitch"? Was the Prez's phone connected to the CLEC switch or the University's miniswitch? (I can already answer part of that... he wasn't connected to any CLEC unless it's a "business class" line. 911 rules usually kill any CLECs chances of selling residential service.)What seems most plausable is the phone being connected to the university phone system (miniswitch, PBX, or more likely a multiplexor.) And that system being heavily overtaxed to the point of not noticing the off-hook event -- I've seen analog PBXs do that. I've been in this kind of telco environment at college (NCSU.) The way the system at NCSU was 8 years ago, if everyone in Bragaw picked up their phone (800+ phones), some of them would not get a dialtone; the multiplexor in the boiler room bridging the phones to the fiber switch in Lee did not have the capacity. (Voice barely worked and modems were a lost cause.)
Because CLECs sell channel services instead of bandwidth. It's like buying a POTS phone line... the telco is "required" to have the switch capacity to handle every line. (That only means you get dialtone from the switch everytime you pick up the phone. Interswitch capacity can and does cause failures -- "all circuits in use".)
No where have I seen anything to suggest Cogent is promising 100Mbps from any point in their network to all other points in their network. Your router to their switch is 100Mbps. That's about it. (QoS isn't free. In fact, it's one hell of a revenue generator.)
I knew someone was going to force me to give this long and generally cryptic description...
Where I work, we use Rational Clearcase for version control (etc.) Unlike conventional builds, the only explicit dependancies that must be listed in the Makefile (which is, itself, under version control) are critical elements outside clearcase. Clearcase audits builds to construct configuration records enumerating what was done to create an object (called a derived object.) That includes every clearcase file referenced, the commands executed ("build script"), and environment variables referenced. Clearcase evaluates that information to see if it needs to rebuild it (or "wink-in" a copy someone has built -- use their copy instead of compiling it yourself.) That works perfectly with any sane langauge.
HOWEVER, with java, that's a nightmare. Allow me to demonstrate the complexity of the problem which you you seem to have ignored. When you run javac, it will recursively compile everything it needs. It will not verify the up-to-dateness of class files. If foo.java requires elements from bar, it's only going to look for bar.class. If it exists, it uses it - period. It will not look for a source file or try to rebuild it. If bar.class isn't available, then javac will build it in the process of building foo.class.
In the realm of clearcase, this creates a very serious problem. Let's say you have two java source files: foo.java, and bar.java. In the Makefile, they are entered such that they will be built in that order. If foo requires elements of bar, then the first time javac is invoked, you'll end up with foo.class and bar.class and configuration records showing the coresponding java source files were referenced. Then the build system will see bar.class exists and evaluate it's CR. It's build script won't match and thus gets rebuilt. If you run clearmake again -- having changed nothing, foo.class will get recompiled because bar.class is now different.
The problem is that java source is compiled from java object code. The result is an impossible nightmare for build and configuration management. No one can list every damned dependancy for everything in the Makefile. You cannot carefully order things in the Makefile to control the compile sequence (so bar is always evaluated before foo, etc.) Even if you did manage to build the dependancies into the Makefile and maintain them everytime a line of code changes (never gonna happen), you'll still end up with overlaped, circular dependancies; foo depends on bar who depends on baz who, in turn, depends on foo (I trust you can see the mess; one of them will always be out-of-date.) Suddenly you have to put special rules and targets in the Makefile to deal with clusters of source files.
You are correct in stating javac is not a compiler in the normal meaning. However, without 3rd party products, that's all one has to compile java source into java bytecode. So, there are very few options... You can go the complex route and wire everything into the Makefile and watch the source and compilations closely for the rest of eternity (read: pray.) You can take the shutgun approach and rebuild everything when any source file changes -- part of the build already does this, but I don't like it. Or find a 3rd party tool to hide part of the complexity.
Right now (if I could get the developers to make up their mind and stick with one JDK and one IDE) I'm building everything with JBuilder's bmj tool. It's not perfection, but it's at least consistant (mostly.) Even with bmj, I still have problems with overlapped dependancies -- one package depends on another or projects building on each other. Right now, the source tree for this development is rather small, but it's growing and will continue to grow -- there's 1.4G of C++ source, how much java source are we going to have in a few years? (I don't want to think about it.)
- As for serving up a web site, servlets and JSP are compiled down to bytecode, and unless your perl or PHP script has been compiled down, that Java bytecode is going to run *plenty* fast.
And that's one of my problems with JAVA... damned bytecode. Everyone moved away from BASIC because it's a tokenized, and therefore interpreted, language. This's nothing different in java bytecode, but everyone fsckin' loves java for it. It's all still binary instructions for a nonexistant processor. (Ok, Sun did try to push a java (co)processor, but it flopped.)JAVA as a pure programming language is, more or less, C++. [C++ for people who shouldn't be programming in the first place, IMO. Maybe I taught FORTRAN labs a little too long.] The only real difference is the lack of header files to define data structures -- java gathers everything from the object code. That, in itself, is both an interesting feature and a major, major nightmare for build and configuration management (something I'm paid to do.)
To be fair, a java servlet is the same thing as compiling a C/C++ CGI into the web server. BTW, you can do that for apache and a few windows web servers. (apache DSO's and windows DLLs)
It doesn't mess with horizontal anything -- and certainly has nothing to do with timing.
Macrovision places a superwhite ("high voltage" as far as a video signal is concerned), high freqency pulse in the virtical blanking interval (VBI.) The pulse is designed to confuse the gain control circuits (the AGC - Automatic Gain Control) within the VCR. AGCs in TVs are slower to account for transient noise in the broadcast signal (modern TVs have macrovision "hardened" AGCs). VCRs are trying to record the signal so they have to adjust rapidly -- 30% too many electrons ("over white") fired at a phosphor pixel doesn't nothing; 30% too much voltage on a VCR R/W head is a magnetic disaster.
Things have changed since Macrovision was developed. Now, everything understands it and knows what to do with it. For example, the TiVo knows when Macrovision is present in the input video and (theoretically) stores that in the mpeg data to know to enable it when it plays it back. Almost all video codecs now support detection and reporting of Macrovision. Two of my VCRs don't care about macrovision at all -- they record is along with everything else without distortion.
I use the phrase "H-Card" so I'm a DSS pirate? First off, I don't have DSS (or cable :() None of my friends with DSS are stealing it -- even those who have H-card based hardware.
As for my point... the user interface, I've never liked the RCA crap -- it's slow and feels cluttered. And I don't like the new Sony's -- the interface is ugly compared to the original DSS receiver (yes, it's h-card based. that's all there was then) and much slower.
The ReplayTV's UI looks too much like a Ted Turner colorized TV Guide. The Tivo tends to waste screen realestate, but it's very easy to read.
The older ReplayTV's do have a firewire port. That hardware isn't free so someone, somewhere obviously had some plans for it. Archival might not have been one of them, however. It's more likely it would have been for attaching a digital camcorder. It doesn't matter anyway as the current units no longer have the firewire port.
I'm the one who's supposed to be embarassed? Leto asked and I answered. Did you ever see the old nugget-stats? The bwilson-stats isn't significantly different.
DCTI has had problems with stats for years and years. There were problems with statsbox being heavily overworked back in March/April of '97 when I first became aware of d.net. Problems have remained to the present -- insufficient processing power, too little drive space, missing logs, incorrect processing, database corruption, intermittent instabilities ("nothing changed, but it failed today."), etc. One would think after three years someone would have shoved a clue up DCTI's ass; I, at least, tried -- it sat on foobar for months and nugget never lifted a finger to even look at it (it's still there, btw.)
I know it's a volunteer effort (or was), but come on, this isn't quantum physics. If the keymaster or proxy network were handled in the same manner as stats has been, d.net would never have gone anywhere. Of course, the bottom line is that Nugget had nothing to do with the design of the proxy network.
*shrug*
DCTI is still decompressing logfiles in place:
- open GZIP, "gzip -dv $workdir$basefn 2>
/dev/stdout |";
And copying the result into the database:- open BCP, "bcp import_bcp in $finalfn
... -c -t, 2> /dev/stderr |";
And then performing the tabulation:- if(!open SQL, "sqsh
... -i integrate.sql 2> /dev/stdout |") {
At least, integrate.sql uses a running total instead of Nugget's original summation to the beginning of time method. There are still significant issues to be dealt with that DCTI hasn't suggested they're even aware of. (Just how big are the tables? How fast are they growing?)stats::log($project,139,"Error launching sqsh, aborting hourly run.");
die;
}
[Note: It's actually less efficient now... logmod_rc5.pl reads the entire decompressed logfile and spits it back out with a 4-digit year and project code. Gez, that's a 5 second modification to the proxy source.]
The RF box physically supports this, but the TiVo UI doesn't have anyway of activating it. (Note: the TiVo powers up in pass-thru mode. That's why the "loading" screen isn't shown on the TV out.)
And yes, that's a serious pain in the ass when you have an antenna to aim with a two second display delay.
IMO, both user interfaces suck. I hate the way ReplayTV tries to pack too much onto the screen (and that color scheme doesn't help.) The TiVo wastes half the bloody screen. If you've ever used one of the old (H-card based) Sony DSS units, that's the kind of interface these things need -- that's a very good use of screen space.
ReplayTV could certainly have crushed TiVo... their older units have a firewire (usb?) port that could have been used for digital archival -- something no current TiVo can ever do.
- How could dnet [stuff]
/reduce/ your interest in them?
Many people will see this as DCTI "selling out". DCTI was formed by a losenit group of people in their spare time, as a hobbie. There was never any commercial intent. It was completely volunteer. No one was paid for anything; they did it because they wanted to. It was something "cool" to take up one's time. The spirit and ethic onwhich DCTI was founded has been betrayed. Maybe this is/was inevitable."new stats server"? When is DCTI going to stop throwing hardware (by translation, money) at badly designed processing?! The daily stats run can be done in minutes, not hours, and not require gigs of temporary database space. Two+ years ago I volunteered to assist in speeding up stats as the poor little dual pentium was dripping blood for hours everyday running the RC5 update. I screamed when I saw how things were done -- in nugget's words, it was designed to run, not run fast. I wrote a logfile processor to handle the tabulation of the keymaster's log files. The initial tabulation is what took 3-4 hours -- ungzip, BCP, sql query to tabulate. Factor in the size of the dataset (much larger than RAM) and how many times it was read from and written to disk and you can see what those hours were spent doing. The processor did the equiv. work in under five (5) minutes; plus the dbm hash storing the tabulation is additive (process each logfile as it comes in from keymaster) and perl compatible. However, nugget never looked at it; it went with me when I left. The process can be sped up even more...
You can read can't you? I'm "cramer" not "cowie" and I've not been in #distributed for a very long time. And I've not been on EFNet for a few months -- I have more important things to do than hunt for a server.
As for bitter... nah. What reasons do I have for being bitter? (with this commercialization, I guess I have one more.)
You bring up an interesting point. DCTI, as you have enumerated, has four "core" technologies: RC5, DES, CSC, and OGR. The RC5 stuff started out as genx and eventually became what is now DCTI. (It wasn't DCTI until sometime after genx folded. It was Distributed Computer Processing, or something like that prior to incorporation.) RC5-56 and RC5-64 are the same core. The switch from 56 to 64 was lightning fast -- on the order of days.
DES. To the best of my recollection -- and I was part of d.net then -- no one within DCTI wrote, from scratch, on their own, a DES core. Everything started out with brydDES and a generic "C" core. Later a "bit slicing" core was provided that made a significant difference to some platforms (most notablly, the Alpha.)
CSC. An interesting if little known factoid... It took DCTI an excessively long time to include CSC capabilities to the clients despite having had the source for a CSC core for months. And they later announced they would not be optimizing their CSC core -- translation: they are going to take what they were handed and run. (As I was told, the C code core came from Remi.)
OGR. This was my first "official" involvement with DCTI which eventually brought me into the inner circle (#dcti and the cursed "+o".) I took gasrp (garsp32 as I recall) and made it "core-able" which is to say it could be started and stop from any arbitrary point (well, at a clean stubing point anyway.) That was in late '97 -- the OGR-21 era. It took almost two (2) years and incorporating Greg Hewgill and the entire Golumb Ruler project to begin processing OGR. Granted, it's a different beast, but it shouldn't have taken that long.
DCTI used to be vary good at giving credit where credit is due. However, looking at the current credits page, they seem to have aquired a very selective memory. The only place you find my name is in the ledger despite over a year of contributions as a general coder, porter/builder, proxy op, and even keymaster briefly. (One of the NICs got fried. The new motherboard was never used because nugget refused to replace a dual Pentium 200 (233?) with a single but dual capable PII 300. Nugget's rant about SPS to MPS is bull... you can install NT as MPS on a single processor system and then stick a second processor in there later. It's one of the first questions asked during installation -- video card, keyboard, system type. But I'm not bitter.)
If you've ever watched any of the shopping channels, enormous collections of things tend to appear out of nowhere every few months. I especially like seeing them sell the same "we've only got twenty in the warehouse"/while they last swords every week.
(BTW, I've got several TiVo's so I'll never be bored enough to let that crap stay on my TV. In fact, my tivo's don't even know channel 30 exists.)
If you wanna be famous, perform a differential crypto-analysis of a series of buffer files. When you stop laughing, publish your results (and thus how DCTI's client communications are scrambled.)
You could do the same thing by disassembling the client, but what would be the fun in that? Besides, DCTI might (correction: would) send a legion of lawyers after you.
I'm amazed that no one has "broken" the encryption. Especially seeing how many hacked clients there have been -- I guess NOP's are faster to insert.
Since when is United Devices "a big company"? In most respects, DCTI is a bigger "company". UD's site does give many details about it's formation. They recently received their 13M$ in funding and sucked in high profile people (SETI@Home and D.Net.) How many people knew about/of United Devices prior to today?
From what I gather, this has been in the works for some time now. (Maybe not UD, but some form of commercial direction.)
Not necessarily. Database design is one of a very few true black arts (read: serious voodoo.) The number of queries alone isn't a problem. The layout of the data, indexing, number of queries, complexity of queries, and the volume of returned data all factor in.
Let me provide a real world example. Some years ago, it was my task to roll out RADIUS for an ISP's dialup network. The stock setup for the USR RADIUS server -- it was the only one I could get to talk to a SecurID server correctly -- was, shall we say, non-optimal. USR's stats said one (1) authenication per second when using postgres. Let's ignore the way they had postgres setup (fsync enabled) for the moment. The reason everything was so bloody slow was the database schema. Even though there was only 1 query against the USERS table, it had to return 5k. Each row of the USERS table contained everything you could ever imagine (well, that USR could imagine.) Each row consumed almost 5k of space.
After three months of testing, data collection, and analysis, I redesigned the mess. USR literally laughed at my design because it made between three and six queries depending on the user. They stopped laughing when I showed one of their engineers the setup actively handling over 100 authentications per second. The USERS table, holding 10,000 entries, was about 2M.
As I recall, postgres is designed (optimized) for a PPro. In my testing of postgres (it was the only DB the RADIUS application knew how to talk to), a 486DX50 was faster than a 533 Alpha -- running 6.2.1 (as you can see, that was a while back.) I've not done any tests since "time travel" was removed -- and boy did that make a difference.
Too be fair, let's remember postgres and mysql were both designed completely differently by different people for completely different tasks. Each does what the creators see as necessary.
And, for the record, MySQL does has transactional capabilities -- I'm really surprised no one has posted this. There was a press release some months ago about this complete with instructions on how to activate support for transaction when building. (Note: I've not tried it.)
And while we're comparing databases, why not compare against some commercial engines like Sybase and/or Oracle? I know Oracle will shit kitten, but do it anyway.
"Political program[s]"??? Gez. Don't bother wasting your time trying to teach these kinds of people how to live in society. Weither they are 10 or 30, they should have learned this kind of anti-social behavior is inrolerable. They should have learned that when they were 5. All that matters to them is their own tiny, insignificant piece of the world. Someone wrongs them (as they see it) so they strike back at the entire world. If their parents had taken a few seconds of their lives to actually participate in the upbringing of their children, maybe we wouldn't have so many mentally unstable people. "Spare the rod; spoil the child."
There's little point in investing the time (and my tax dollars) in civilizing the uncivilized. We spend enough on rehabilitating criminals who go out to commit more crimes. And while jail time does correct some, it's statistically worthless.
(I think it's time for another flood. Oh, wait, He promised never to do that again.)
Therein lies the problem: it takes NO experience to be an asshole or a script kiddie. (To some, being an ass comes natural.)
According to some articles I've read (sorry, no links), there are comparably few "hackers" and hundreds of "idiot" script kiddies who take the knowledge and (hard) work of the real hacker to do their childish shit. You've obviously never heard of a "rootkit" or a "DoS kit". They aren't entirely to the level of click here to break in but they don't require any "hacker" skills.
Personally, I think the Ido (ST:TNG) had a good idea... "There is only one punishment for breaking any law: Death." People (and I use the term loosely) perpetrating such things are more than proving their inablity to live and participate in a civilized society. I say treat them accordingly. If you had a dog that constantly ate the funiture, crapped in the middle of the living room, and pissed on the china, you would not tolerate it. It would be punished, exiled, banished, and/or executed.
When you act like a two year-old...