The p4 command-line tool. This is definitely the most full-featured, and if you're experienced with command-line tools, easiest to use. It has the full functionality of the system in the tool, as well as some nifty scripting bits (like the -g option, which returns all output as marshalled Python dictionary options, or the -s option, which prefaces each line with a tag letting you know if it's Info, Warning, or Error to grep through more easily).
P4Win, which is the standard windows GUI. It's raelly full featured, and looks enough like other similar tools that even our non-technical people use it on a regular basis.
P4Web, which is a little mini-web server that runs on your machine and presents a GUI view for those who aren't on Windows. The P4Win GUI only runs on Windows, but P4Web runs on pretty much everything, and provides essentially all the same functionality as p4win and the p4 command line tool, it just has the latency gap of being a command-line tool.
P4Ftp, which is an FTP daemon which again presents an FTP view on the depot. While this might not seem great, it's a HUGE boon if you work with a bunch of tools that allow you to save to an FTP server and you're not a technical person (think: web designers working in DreamWeaver). Rather than teach them how to use a command-line tool or deal with a version control system, just stick P4FTP in front of them, and every time they close the FTP connection it will submit the change to the depot.
Most functionality is provided in all tools (except P4FTP), but the P4 command-line tool works the best for me, and I use it even on windows for a lot of stuff. There's also integration with Ant at this point for many commands based on running the command-line tool.
I know somebody else has mentioned this already on this statement, but you should really take a look at Perforce. They've got high level technical overviews and comparison with CVS. But it fundamentally solves everything that you say you're lacking right now:
Logging: P4 is much more server-centric than CVS, so at any time you can see what files are opened by which developers on which machines, which is one of the things that you're looking for. In addition, the ChangeList metaphor that it uses for atomic changelists ties the whole thing together by allowing you to easily do lots of tracking by changelists. Finally, you can do a lot of reporting with the built-in tools, such as "show me the last 10 submissions by Bob" or "show me all changes to affect that branch of development".
Branching and Merging in Perforce is great. Fundamentally, it keeps track of the different file revisions as separate subtrees of the system. So, for example, you can have//dev/... (the current development branch),//dev/v2/... (version 2),//dev/v3/..., etc. Or you can have//dev/...,//v2/...,//v3/... You can pick and choose precisely where you have branch points however you choose, and because that mapping ends up affecting the client's file hierarchy, users have the same hierarchy for different versions of the code hierarchy at the same time. Merging is incredibly easy (we currently have 4 active branches of development, and it's reasonably easy to keep them all in sync).
I think what you want is to be able to see who's working on something. Let's say you've got a binary file checked into CVS. Two people might be working on it. How will they know? Are they expected to email everybody else that they're working on it? What happens when they try to reconcile the changes? P4 handles this by keeping track of who's working on what file, WITHOUT locking the files. So you can have two people working on the same file, but they at least KNOW about it at the time that they're making their changes. Furthermore, for troublesome binary files, you can now have a file attribute on the server say "multiple people can read this file, but only one person can have it checked out." You can control that on a per-file, or per-file-type (such as "all.doc files") basis, which can be huge for the few files that inevitably have those problems.
I'm not sure what you're talking about with the lack of true version control, but P4 has a very strong transactional background, and perfectly atomic submissions (which CVS does not). It's impossible to synchronize to an inconsistent state without specifically wanting to do it. If you're talking about RCS file corruption, P4 stores digests of all the revisions of all files in the depot in order to ensure that it can recover from RCS corruption (or at least detect it, I'm not sure since we've never had a case of corruption there).
There are even tools for automatically taking a CVS hierarchy and putting it into P4. I've not used it, but apparently it's quite easy to do.
The biggest change that people I've seen always notice is the fact that with CVS, you just start editing files and it'll figure out later how to work that into the server. With P4 you have to tell it, which is not that great. However, there's a tool called C4 which a couple of our engineers who are most comfortable with CVS use which presents a view almost identical to that of CVS (except for the specific P4-isms), so that the learning curve is greatly decreased.
Actually, kinda. We use Visio to create our UML diagrams (so the few people that actually draw them have to have Windows, other than that all engineers use Linux or Solaris), but then we translate the drawing (which is just for pictoral reference) into another XML DTD.
That one gets fed into a custom repository system which automatically generates all the code we need for using the objects, including javadocs and XML documents, when then go into the rest of the channel for documentation. The repository system also generates multiple types of storage back-ends (Oracle, Postgres, Java Serialization, In-Memory-Only, etc.) so that the engineers never have to worry about data access code, and we can change what type of storage we're using at a customer site.
So in that respect, we're using Visio or MagicDraw just for the documentation of the UML model, but the "real" model is always in XML and only used by the repository system we've developed.
I asked our docs infrastructure person to pipe up, I'll see if she does before this gets to like 400 comments and nobody sees.
We standardized all our early documentation on XML, and it's been working great. Admittedly we're using Perforce, not CVS, but we're doing something very similar to what you want to do.
All our documentation is in XML format, in a DTD that we defined. We then have XSLT transformation scripts that convert that documentation to HTML format, and scripts that automatically update our development intranet whenever changes get checked in, along with scripts that invoke javadoc and doxygen on all the code to convert that to HTML format. We're in the process of being able to convert the same documents to PDF format to be able to publish those same documents, in the same formatting, to pretty-formatted documents for printing.
This, aside from the simplicity of not having to worry about formatting documentation when you write it, is pretty cool. It's easier for me (as an engineer) to write a very sparse, structured XML document that will end up looking very good on screen, than to learn enough HTML to make my documents look good. And it's easier for us to enforce a standard look and feel across all documentation this way, because only the XSL transforms have to change if we change our formatting.
But the real advantage is coming out with more advanced uses. For example, when we have configuration files, we have a special DTD that we define the documentation for the configuration files in, and then any documents that describe the configuration files are automatically converted both to the HTML documentation, AND to an example configuration file for users. We can also mark some things as only visible internally, so that the same document can have data that's visible to end-users, and data that's visible to employees (so if we have advanced configuration options that we don't want customers mucking with because they're for debugging the system, we can document them in the same place, and just hide them from customers but let our support and professional services people in on the secret).
The best part is that because our XML DTD is very structured, someone like me (an engineer), will actually use it because it ends up being easier for me than writing in plain text, whereas I wouldn't do it in HTML (or if I did, it would just look like crap).
It also makes it much easier to do integrations across branches of code: because we know the DTD for our XML documents very well, it's more likely that integrations will go smoothly, which helps keeping multiple branches of code and docs in sync automatically. If you go with a binary format, you're not going to be able to do that, and every time you make a change, you're going to have to manually change the documentation for each and every branch. With ASCII or HTML, everybody's going to produce documents that look a little different, so you're not going to be able to have as easy a time in integrating between branches.
Our docs infrastructure person can pipe up in terms of the particular technology that we're using, but it's turned out to be one of the best infrastructure decisions that we (actually, she) made, and it's saved uncountable hours and actually made it more likely that people will write documentation themselves, because they don't have to pull out some crazy windows tool: just edit the document in emacs, and it'll still look pretty for the customers.
I seem to recall that Mandrake 7.0 or 7.1 would do that with postfix straight out of the box as well. You would have to manually go in and set it up if you wanted anything other than a workstation-only setup. I can't recall off-hand whether it would not listen to the network at all, but I know that it would set itself up as a pretty secure (from spam and other mail issues, including crackers) environment right out of the box. I always liked that a lot about Mandrake back in those days.
But I think the point is that he doesn't want to. Running your own infrastructure is time consuming and resource intensive, even if you're just spending the time to set it up. Why not outsource it if you can?
He might also be somebody who's savvy enough to know what he wants, but doesn't want to spend the time and effort to constantly evaluate the latest and greatest packages to implement what he wants. Why not just leave that headache to somebody else entirely?
I think it's reasonable to point out to many of the people responding here, and the author of the post might not have thought about this, but what if you really just don't want to manage your email infrastructure? I mean, it's essentially a utility at this point. What if he just doesn't want to bother?
Email is reasonably easy to set up, but it's quite important to get it right, and maintainance of it can be quite difficult at times. And if it really is that easy, then all the more reason to outsource it, because then you're at absolutely zero maintainance. But in terms of backups, even if your colo does provide it (it's an additional fee at someplace like exodus), you have to setup the scripts. And if something does go wrong, you're expected to be integrally involved in the resolution. Why not just let somebody else handle that altogether?
But the bigger issue is that email provides complete economies of scale. Figure he's a small installation (as he said). I doubt he'll have need for more than 1GB of total mail space (including spooling and IMAP space). With his own box, figure 1GB for software, and 1GB of email storage. For that he's got to pay for 1RU and a box to go in it. That box can almost certainly handle a lot more than just him. If the outsourcing company is able to put 10 or 20 such customers on the same box, then you're spreading the cost of the box, the disk, the maintainance, the backup, all amongst 10 users. And a lot of outsourcing companies will use something like a medium (280R or 420R) sun box for that, with 100-200 customers, all in like 4-6u (2u for storage).
Finally, there may be some advanced features you might want to use that would justify a commercial server (like Sendmail, or OpenWave, or InterMail). 5 users is not enough for those companies to even write a quote (you might not need the features, or you might), but if you're able to get a bunch of users doing it, and one person maintaining the system, you're in the clear.
I suppose the critical issue is whether you believe in the economies of scale, and whether you get a kick out of maintaining email. If you don't, don't bother with maintaining the thing and try to outsource it.
By the way, the closest Exodus location to Aberdeen is in London. Not really a "stop by and muck with the box" sorta distance.
If he did that it would DEFINITELY end up as a legal conundrum. A company with shareholders and a board cannot simply have an executive donate ANYTHING of that much value on a whim. The creditors would sue Andy personally before he finished assigning the copyright, and the FSF claiming that he had no right to assign the copyright like that. And they'd probably win. You can't do stuff like that when you're going into liquidation.
HP's OpenMail product had the distinction of being the only mail server software running on *nix (including Linux) with full Exchange Server functionality. It's been End-Of-Lifed, probably because of some Microsoft pressure.
It already is to no small extent, through the use of things like NSF grants for university research projects which result in open source code. Consider:
BSD
PostGres
Mosaic
Sendmail
The UW-Imap Server (this one I'm not sure about the funding on, just the source)
Cyrus tools (again, not sure on the direct funding)
WU-FTPD (again, not sure on direct funding)
Pine (another one like UW-Imap)
the NCSA Web Server (which transmogrified into Apache over time)
All came from government-sponsored university research projects. Even where the link between a funding grant and a project isn't direct, so much university research is government funded that it's difficult to separate out those projects which are university produced, but not the direct result of a government grant.
A Microsoft executive will give a speech saying that when you trust an open source technology, your business will be relying on someone who is about to go under, leaving you with no opportunities for commercial support.
The sad thing is that the CIO crowd will actually read this and think, maybe just a little, "yeah...".
Was. From what I've heard, at this point they've removed virtually all of the Sybase code. MS SQLServer 6.5 was almost all Sybase code, 7.0 and 2000 are virtually NO sybase code.
There IS some interesting technology at Informix, you just have to know what it is. Look at ZDNet Article on it. The main thing they're buying it for, somewhat, is the data warehousing capabilities. This is actually someplace where IPS (Informix Parallel Server) has a reasonable advantage.
Informix has two main enterprise products: IUS (Informix Universal Server), which is the result of the Illustra integration; and IPS, which is the massively parallel server. IPS is actually pretty widely respected and used. It's a monster for data warehousing, and is very commonly used in large (i.e. bricks-and-mortar) retail installations. In fact, a very common installation platform for large retail is to use IBM (mainframes, AS/400, and POS terminals) for the transaction processing, and IPS to handle analysis.
So in that sense, there's both interesting technology there (the massively parallel bits in IPS) and a very good synergy of customer base and products.
So in direct response, there IS interesting R&D out of the Portland lab where informix did the XPS work (I forget if they're actually calling it XPS or IPS these days, it used to change around a lot), you just didn't know it.
And the research you're probably thinking of comes out of Almaden. There's some interesting DB/2 related work out of Santa Theresa, but Almaden is where the really cutting-edge stuff has taken place IIRC.
Re:cameras in school too much work for parents
on
Sean In The Middle
·
· Score: 2
Many security cameras have a single (or several if it's a complicated scenario) tape installed which is one of those looping tapes. Either the tape itself loops around to the beginning when it's done, or the camera rewinds the tape automatically when it finishes. Thus if you have a 1hour loop, at any given point you will only have 1 hour of history.
Every security scenario uses some form of this. Otherwise you'd never be able to store everything that goes on, because it's an infinitely increasing amount of data. So whether it's a looped tape, or a recycling policy, you have a window to discover that something happened and to grab the tape in question. Otherwise the tape will be recycled and then the data is gone for good.
it's just like tape backing up your computer. You can't possibly afford enough tape to never recycle one, so you institute a policy which gives you usually a 1 or 2 week window. If you discover you need to restore something, if the damage happened more than 1 or 2 weeks ago, it's gone for good.
What he's saying is that there was such short recycling on the tape used that by the time they realized there was a problem it was too late.
I think you hit the nail RIGHT on the head several times. You assume that the primary motivation for what Trolltech does is whatever is good for KDE, which you see as their primary consumer. But as far as Trolltech the corporation, they should be completely and 100% ignoring what KDE wants when it doesn't jibe with their primary focus as a company: corporate consumers. What direct revenue does Trolltech get for KDE? Pretty much Zero.
What they're really doing is getting things in Qt up to a level of MFC or something like that (with the database-backed widgets, which have been in PowerBuilder and Visual Basic for a while now) so that it can be seen as a more complete solution for corporate development.
Remember, Trolltech is fundamentally a company, and as such has to get revenues, and thus needs to write things which will be useful to their corporate customers, not non-revenue-producing users of their technology.
If the focus here is why should FREE software developers care, well, they'll ultimately have much of this through KDE anyway. Otherwise, there are a lot of corporate types who read Slashdot anyway.;-)
So this is something which probably won't help you that much, but back in my university days I ended up working on quite a few keyboards (I'm currently addicted to the Kinesis, because my CTS got bad and my doctor "recommended" that I switch to something like that).
The lightest touch I ever had was on the ones which Digital was selling with their Personal DECStation and original AlphaStation line. You could barely feel that the key had moved, and there was virtually 0 tactile feedback, the key action was so low. They stopped selling computers which used them a LONG time ago (when they went to a new generation of AlphaStations), and they didn't have standard keyboard attachments (some crazy DEC thing). However, it was the lightest touch ever. And if you wanted (I did) you could set it up to issue a very low click-style-electronic-sound when you hit a key, to get over the "did I really hit that key" effect you have with something like that.
At one point I was using FreeBSD and SunOS, and I actually would telnet into the machine that I really needed to work on from the alpha box (even though the freebsd box was right next to it) just so that I could use that keyboard. You might be able to pick up a really cheap DECstation or AlphaStation (the really old ones that used the same chassis as the DECstation they replaced) on eBay or something for dirt cheap. Not the fastest machines in the world, but this stuff worked really well.
It's probably rightfully considered an HTTP header indicating that what follows is HTML. HTML is only considered in the payload of the transmission, and that occurs in the HTTP header before you get to the payload. Otherwise, it would make little sense to have text/plain as a Content-type, since you can transmit that over HTTP with no HTML coming in at all. Content-type: text/html just indicates that what's about to come over the wire is in HTML form.
And of course, your representative will never be there because he or she almost certainly has a "second" residence in washington where he or she lives 9 months out of the year. And of course, the secret service probably won't like knocking on his or her door.;-)
and even though I know the process inside a congressperson's office, I was still surprised that in every case, I've received no response whatsoever. I wrote letters, printed them out, signed them, made sure to send them to the offices of my representative and both senators, and got nothing in return. No "thank you for your concern but you're a flaming idiot" even.
Admittedly, whenever you send anything to a congressperson's office, that person will VERY seldom actually read it. They have interns to evaluate those which can get form responses, those which can be completely ignored (apparently I've always been in that category), and those which should go to the attention of the congressperson himself. Only things which require action go to the congressperson, everything else just gets tallied.
But I'm still surprised at the total lack of response. Maybe the overall trend is to just ignore everybody these days and wait until the poll numbers are in. If so, then the issue of ignoring email is part of a larger trend: politicians don't care, or don't have time to respond, to all the demands placed on them by their constituents.
Imagine you're a standard representative. Imagine you have what, 10 staffers? (I don't know the exact number). Imagine you get just 1000 emails and letters and faxes a day. How are you going to actually get through all those. If you expect that each piece of correspondence requires some kind of response, and you have 10 staffers, each one has to get through 100 pieces of correspondance a day. On a 10-hour day, that's 6 minutes per piece of correspondance. You're never going to get any ability to deal with ALL that on an ongoing basis, so you have to figure out very quickly what to drop and ignore.
Because if they're round, no matter how the manhole cover falls onto the opening, it won't fall through and hurt the person standing underneath. If there's any points, that implies a cross section bigger than another cross section, so the cover could fall through and hurt/kill somebody underneath if it came down wrong.
I think that this has to depend on the attitude of the students involved in the program, and how much they need mentoring in their studies.
I went to one of those heavily research-oriented schools, and while lectures were quite large (class sizes of like 150-200 people for upper division CS classes), a lot of people still learned a lot. Part of it comes down to your personal style. Are you willing to seek out the professors and ask them questions and talk to them during office hours? While a class of 200 people means that of necessity the professor did NOT go out of his way to get to know any individual person, if you made an effort to speak to them, they definitely remembered you and would have conversations about the work. So in that respect, it's one of those things where if you decided to make the extra effort to get to know your professor, you'd get some of that same one-on-one interaction.
It's MUCH easier to hide in the crowd at a big, research-oriented university. It's much easier to never make the extra effort to get to know your classmates, or your professors. And for some people, that's great because they WANT to blend in. But at least at my school, those who made the extra effort were always rewarded for it.
But there was one advantage which I couldn't have gotten at a smaller program which didn't have a research focus, which was the chance to do research itself. I did a year of research in one of the research groups as an undergraduate, and was a full participating member of the projects I worked on. Having that opportunity (as well as the opportunity to take graduate classes as an undergraduate) was huge for me, and probably was the most defining part of my undergraduate education. If I had been at a school with less of a research focus, it never would have been made available to me. Quite a few of my friends did the same thing. Again, you have to go out of your way to do it, but almost all the professors had extra research grant money to spend on undergraduate research (the NSF does lots of HUGE grants JUST for this).
I'm not saying that this style is for everyone, but being at a research-oriented school doesn't preclude you from having individual one-on-one education, as long as you've got the sort of personality where you'll go out of your way to get that kind of attention.
Asynchronous vs Synchronous execution
on
Messaging vs. RPC
·
· Score: 5
I think someone pointed out the queueing nature of messaging as opposed to RPC, but let me point it out here. There are multiple ways of doing RPC, some of which encapsulate your parameters in some kind of abstract notion of a "message" or "packet" (such as XML-RPC). However, they all have one thing in common: they're synchronous protocols at their core. You make a function call, the parameters are marshalled on the client, transmitted to the server, unmarshalled, the function is executed, and the result is marshalled and unmarshalled. This all happens in one thread of execution on the client, it seems like you called a local function.
Messaging, on the other hand, is typically asynchronous. You prepare a message, and then pass it off to your client-based message handler. Then, at some point in the future, it's guaranteed to be executed. You might say you want an asynchronous notification of when it executes, you might be able to poll at a later time for the result, or you might just trust that the system is going to handle the situation appropriately. But the moment the parameters are marshalled on the client, the client can and will continue with its work.
It's a fundamentally different model for many cases, and sometimes is NOT appropriate for application logic. And at its core, you can implement RPC over some kind of messaging system (in which case the client libraries will just not return from the "enqueue" call until they've gotten the "executed" event back from the server), but that's not what people use it for.
There are a couple of things which messaging then gives you which conventional RPC does not:
You can very easily scale out your number of servers with messaging. While with XML-RPC or SOAP you could in theory just stick a load balancer in front of your server farm and scale out that way, enterprise messaging is more designed for the case where you have multiple servers handling multiple clients, and enterprise systems will make this very easy to handle.
You can pass the same message to multiple servers, thus allowing you to update multiple systems at the same time if it's an update type of message.
Messaging typically involves transactional semantics. Once you marshall the parameters on the client, the underlying system will guarantee that the message gets delivered, assuming the system doesn't explode (for example, if the server happens to be down, when it comes up the system will deliver your message, but if it never comes up the system will just hold your message forever unless you have an expiration).
Enterprise messaging systems are designed to integrate with transactional environments very well, while RPC is not. (you're doing a transactional call with RPC where the transaction began on the client. Who owns the transaction now? Big question with RPC. For most messaging systems, it's clear that it's all just one transaction).
In short, the primary difference is that RPC typically connotes synchronous execution, while messaging is typically asynchronous execution.
On the spec page for the Blade 100, they make a big deal of the fact that unlike every other sun box out there, this one takes PC133 SDRAM DIMMs, not crazy Sun-Specific stuff. So in theory you could go with any vendor under the sun.
Given the difficulties Sun has with providing working RAM, that's probably not such a bad idea.;-)
Slashdot Mirror
Most functionality is provided in all tools (except P4FTP), but the P4 command-line tool works the best for me, and I use it even on windows for a lot of stuff. There's also integration with Ant at this point for many commands based on running the command-line tool.
There are even tools for automatically taking a CVS hierarchy and putting it into P4. I've not used it, but apparently it's quite easy to do.
The biggest change that people I've seen always notice is the fact that with CVS, you just start editing files and it'll figure out later how to work that into the server. With P4 you have to tell it, which is not that great. However, there's a tool called C4 which a couple of our engineers who are most comfortable with CVS use which presents a view almost identical to that of CVS (except for the specific P4-isms), so that the learning curve is greatly decreased.
Each field is a column in a row. Thus 100,000 bugs == 100,000 rows, 100,000 bugs == 100,000 records. 100,000 bugs != 20 million bugs.
That one gets fed into a custom repository system which automatically generates all the code we need for using the objects, including javadocs and XML documents, when then go into the rest of the channel for documentation. The repository system also generates multiple types of storage back-ends (Oracle, Postgres, Java Serialization, In-Memory-Only, etc.) so that the engineers never have to worry about data access code, and we can change what type of storage we're using at a customer site.
So in that respect, we're using Visio or MagicDraw just for the documentation of the UML model, but the "real" model is always in XML and only used by the repository system we've developed.
We standardized all our early documentation on XML, and it's been working great. Admittedly we're using Perforce, not CVS, but we're doing something very similar to what you want to do.
All our documentation is in XML format, in a DTD that we defined. We then have XSLT transformation scripts that convert that documentation to HTML format, and scripts that automatically update our development intranet whenever changes get checked in, along with scripts that invoke javadoc and doxygen on all the code to convert that to HTML format. We're in the process of being able to convert the same documents to PDF format to be able to publish those same documents, in the same formatting, to pretty-formatted documents for printing.
This, aside from the simplicity of not having to worry about formatting documentation when you write it, is pretty cool. It's easier for me (as an engineer) to write a very sparse, structured XML document that will end up looking very good on screen, than to learn enough HTML to make my documents look good. And it's easier for us to enforce a standard look and feel across all documentation this way, because only the XSL transforms have to change if we change our formatting.
But the real advantage is coming out with more advanced uses. For example, when we have configuration files, we have a special DTD that we define the documentation for the configuration files in, and then any documents that describe the configuration files are automatically converted both to the HTML documentation, AND to an example configuration file for users. We can also mark some things as only visible internally, so that the same document can have data that's visible to end-users, and data that's visible to employees (so if we have advanced configuration options that we don't want customers mucking with because they're for debugging the system, we can document them in the same place, and just hide them from customers but let our support and professional services people in on the secret).
The best part is that because our XML DTD is very structured, someone like me (an engineer), will actually use it because it ends up being easier for me than writing in plain text, whereas I wouldn't do it in HTML (or if I did, it would just look like crap). It also makes it much easier to do integrations across branches of code: because we know the DTD for our XML documents very well, it's more likely that integrations will go smoothly, which helps keeping multiple branches of code and docs in sync automatically. If you go with a binary format, you're not going to be able to do that, and every time you make a change, you're going to have to manually change the documentation for each and every branch. With ASCII or HTML, everybody's going to produce documents that look a little different, so you're not going to be able to have as easy a time in integrating between branches.
Our docs infrastructure person can pipe up in terms of the particular technology that we're using, but it's turned out to be one of the best infrastructure decisions that we (actually, she) made, and it's saved uncountable hours and actually made it more likely that people will write documentation themselves, because they don't have to pull out some crazy windows tool: just edit the document in emacs, and it'll still look pretty for the customers.
I seem to recall that Mandrake 7.0 or 7.1 would do that with postfix straight out of the box as well. You would have to manually go in and set it up if you wanted anything other than a workstation-only setup. I can't recall off-hand whether it would not listen to the network at all, but I know that it would set itself up as a pretty secure (from spam and other mail issues, including crackers) environment right out of the box. I always liked that a lot about Mandrake back in those days.
He might also be somebody who's savvy enough to know what he wants, but doesn't want to spend the time and effort to constantly evaluate the latest and greatest packages to implement what he wants. Why not just leave that headache to somebody else entirely?
Email is reasonably easy to set up, but it's quite important to get it right, and maintainance of it can be quite difficult at times. And if it really is that easy, then all the more reason to outsource it, because then you're at absolutely zero maintainance. But in terms of backups, even if your colo does provide it (it's an additional fee at someplace like exodus), you have to setup the scripts. And if something does go wrong, you're expected to be integrally involved in the resolution. Why not just let somebody else handle that altogether?
But the bigger issue is that email provides complete economies of scale. Figure he's a small installation (as he said). I doubt he'll have need for more than 1GB of total mail space (including spooling and IMAP space). With his own box, figure 1GB for software, and 1GB of email storage. For that he's got to pay for 1RU and a box to go in it. That box can almost certainly handle a lot more than just him. If the outsourcing company is able to put 10 or 20 such customers on the same box, then you're spreading the cost of the box, the disk, the maintainance, the backup, all amongst 10 users. And a lot of outsourcing companies will use something like a medium (280R or 420R) sun box for that, with 100-200 customers, all in like 4-6u (2u for storage).
Finally, there may be some advanced features you might want to use that would justify a commercial server (like Sendmail, or OpenWave, or InterMail). 5 users is not enough for those companies to even write a quote (you might not need the features, or you might), but if you're able to get a bunch of users doing it, and one person maintaining the system, you're in the clear.
I suppose the critical issue is whether you believe in the economies of scale, and whether you get a kick out of maintaining email. If you don't, don't bother with maintaining the thing and try to outsource it.
By the way, the closest Exodus location to Aberdeen is in London. Not really a "stop by and muck with the box" sorta distance.
If he did that it would DEFINITELY end up as a legal conundrum. A company with shareholders and a board cannot simply have an executive donate ANYTHING of that much value on a whim. The creditors would sue Andy personally before he finished assigning the copyright, and the FSF claiming that he had no right to assign the copyright like that. And they'd probably win. You can't do stuff like that when you're going into liquidation.
HP's OpenMail product had the distinction of being the only mail server software running on *nix (including Linux) with full Exchange Server functionality. It's been End-Of-Lifed, probably because of some Microsoft pressure.
- BSD
- PostGres
- Mosaic
- Sendmail
- The UW-Imap Server (this one I'm not sure about the funding on, just the source)
- Cyrus tools (again, not sure on the direct funding)
- WU-FTPD (again, not sure on direct funding)
- Pine (another one like UW-Imap)
- the NCSA Web Server (which transmogrified into Apache over time)
All came from government-sponsored university research projects. Even where the link between a funding grant and a project isn't direct, so much university research is government funded that it's difficult to separate out those projects which are university produced, but not the direct result of a government grant.The sad thing is that the CIO crowd will actually read this and think, maybe just a little, "yeah...".
Was. From what I've heard, at this point they've removed virtually all of the Sybase code. MS SQLServer 6.5 was almost all Sybase code, 7.0 and 2000 are virtually NO sybase code.
Informix has two main enterprise products: IUS (Informix Universal Server), which is the result of the Illustra integration; and IPS, which is the massively parallel server. IPS is actually pretty widely respected and used. It's a monster for data warehousing, and is very commonly used in large (i.e. bricks-and-mortar) retail installations. In fact, a very common installation platform for large retail is to use IBM (mainframes, AS/400, and POS terminals) for the transaction processing, and IPS to handle analysis.
So in that sense, there's both interesting technology there (the massively parallel bits in IPS) and a very good synergy of customer base and products.
So in direct response, there IS interesting R&D out of the Portland lab where informix did the XPS work (I forget if they're actually calling it XPS or IPS these days, it used to change around a lot), you just didn't know it.
And the research you're probably thinking of comes out of Almaden. There's some interesting DB/2 related work out of Santa Theresa, but Almaden is where the really cutting-edge stuff has taken place IIRC.
Every security scenario uses some form of this. Otherwise you'd never be able to store everything that goes on, because it's an infinitely increasing amount of data. So whether it's a looped tape, or a recycling policy, you have a window to discover that something happened and to grab the tape in question. Otherwise the tape will be recycled and then the data is gone for good.
it's just like tape backing up your computer. You can't possibly afford enough tape to never recycle one, so you institute a policy which gives you usually a 1 or 2 week window. If you discover you need to restore something, if the damage happened more than 1 or 2 weeks ago, it's gone for good.
What he's saying is that there was such short recycling on the tape used that by the time they realized there was a problem it was too late.
What they're really doing is getting things in Qt up to a level of MFC or something like that (with the database-backed widgets, which have been in PowerBuilder and Visual Basic for a while now) so that it can be seen as a more complete solution for corporate development.
Remember, Trolltech is fundamentally a company, and as such has to get revenues, and thus needs to write things which will be useful to their corporate customers, not non-revenue-producing users of their technology.
If the focus here is why should FREE software developers care, well, they'll ultimately have much of this through KDE anyway. Otherwise, there are a lot of corporate types who read Slashdot anyway. ;-)
The lightest touch I ever had was on the ones which Digital was selling with their Personal DECStation and original AlphaStation line. You could barely feel that the key had moved, and there was virtually 0 tactile feedback, the key action was so low. They stopped selling computers which used them a LONG time ago (when they went to a new generation of AlphaStations), and they didn't have standard keyboard attachments (some crazy DEC thing). However, it was the lightest touch ever. And if you wanted (I did) you could set it up to issue a very low click-style-electronic-sound when you hit a key, to get over the "did I really hit that key" effect you have with something like that.
At one point I was using FreeBSD and SunOS, and I actually would telnet into the machine that I really needed to work on from the alpha box (even though the freebsd box was right next to it) just so that I could use that keyboard. You might be able to pick up a really cheap DECstation or AlphaStation (the really old ones that used the same chassis as the DECstation they replaced) on eBay or something for dirt cheap. Not the fastest machines in the world, but this stuff worked really well.
It's probably rightfully considered an HTTP header indicating that what follows is HTML. HTML is only considered in the payload of the transmission, and that occurs in the HTTP header before you get to the payload. Otherwise, it would make little sense to have text/plain as a Content-type, since you can transmit that over HTTP with no HTML coming in at all. Content-type: text/html just indicates that what's about to come over the wire is in HTML form.
And of course, your representative will never be there because he or she almost certainly has a "second" residence in washington where he or she lives 9 months out of the year. And of course, the secret service probably won't like knocking on his or her door. ;-)
Admittedly, whenever you send anything to a congressperson's office, that person will VERY seldom actually read it. They have interns to evaluate those which can get form responses, those which can be completely ignored (apparently I've always been in that category), and those which should go to the attention of the congressperson himself. Only things which require action go to the congressperson, everything else just gets tallied.
But I'm still surprised at the total lack of response. Maybe the overall trend is to just ignore everybody these days and wait until the poll numbers are in. If so, then the issue of ignoring email is part of a larger trend: politicians don't care, or don't have time to respond, to all the demands placed on them by their constituents.
Imagine you're a standard representative. Imagine you have what, 10 staffers? (I don't know the exact number). Imagine you get just 1000 emails and letters and faxes a day. How are you going to actually get through all those. If you expect that each piece of correspondence requires some kind of response, and you have 10 staffers, each one has to get through 100 pieces of correspondance a day. On a 10-hour day, that's 6 minutes per piece of correspondance. You're never going to get any ability to deal with ALL that on an ongoing basis, so you have to figure out very quickly what to drop and ignore.
Because if they're round, no matter how the manhole cover falls onto the opening, it won't fall through and hurt the person standing underneath. If there's any points, that implies a cross section bigger than another cross section, so the cover could fall through and hurt/kill somebody underneath if it came down wrong.
I went to one of those heavily research-oriented schools, and while lectures were quite large (class sizes of like 150-200 people for upper division CS classes), a lot of people still learned a lot. Part of it comes down to your personal style. Are you willing to seek out the professors and ask them questions and talk to them during office hours? While a class of 200 people means that of necessity the professor did NOT go out of his way to get to know any individual person, if you made an effort to speak to them, they definitely remembered you and would have conversations about the work. So in that respect, it's one of those things where if you decided to make the extra effort to get to know your professor, you'd get some of that same one-on-one interaction.
It's MUCH easier to hide in the crowd at a big, research-oriented university. It's much easier to never make the extra effort to get to know your classmates, or your professors. And for some people, that's great because they WANT to blend in. But at least at my school, those who made the extra effort were always rewarded for it.
But there was one advantage which I couldn't have gotten at a smaller program which didn't have a research focus, which was the chance to do research itself. I did a year of research in one of the research groups as an undergraduate, and was a full participating member of the projects I worked on. Having that opportunity (as well as the opportunity to take graduate classes as an undergraduate) was huge for me, and probably was the most defining part of my undergraduate education. If I had been at a school with less of a research focus, it never would have been made available to me. Quite a few of my friends did the same thing. Again, you have to go out of your way to do it, but almost all the professors had extra research grant money to spend on undergraduate research (the NSF does lots of HUGE grants JUST for this).
I'm not saying that this style is for everyone, but being at a research-oriented school doesn't preclude you from having individual one-on-one education, as long as you've got the sort of personality where you'll go out of your way to get that kind of attention.
Messaging, on the other hand, is typically asynchronous. You prepare a message, and then pass it off to your client-based message handler. Then, at some point in the future, it's guaranteed to be executed. You might say you want an asynchronous notification of when it executes, you might be able to poll at a later time for the result, or you might just trust that the system is going to handle the situation appropriately. But the moment the parameters are marshalled on the client, the client can and will continue with its work.
It's a fundamentally different model for many cases, and sometimes is NOT appropriate for application logic. And at its core, you can implement RPC over some kind of messaging system (in which case the client libraries will just not return from the "enqueue" call until they've gotten the "executed" event back from the server), but that's not what people use it for.
There are a couple of things which messaging then gives you which conventional RPC does not:
In short, the primary difference is that RPC typically connotes synchronous execution, while messaging is typically asynchronous execution.
Given the difficulties Sun has with providing working RAM, that's probably not such a bad idea. ;-)
I'm feeling particularly dumb right now.