Any idea of we'll be seeing a compatible implementation of something that can do everything Outlook can do (including connecting to an Exchange server)? I don't mean just email, but I mean Calendar, Tasks, Contacts booking meetings etc.
As soon as I can get something that would replace this one last piece, then I can switch away from Windows in my company (as I have at home). Unfortunately, the company relies very much on Outlook's functionality, and will not move away from Exchange server, so if I want to move it's up to me to find and install a compatible alternative, but so compatible that the REST of the users can stay on Outlook if they choose to.
In my opinion, this is one thing that any true Office suite needs before MS-Office can be truly replaced. As buggy and insecure as Outlook is, it organizes the company that I work for, and it can not be removed from my desktop until a fully compatible replacement is available. It's the one last thing that ties me to Windows.
Why use 'computer speakers' at all? If you're going to spend some cash, just get a Y-cable and hook your computer up to your stereo receiver's AUX input.
This is the best way (IMO) to get decent sound, and of course, this gives you things like radio, tape decks, equalizer and whatever else you want to add to it. Add a subwoofer to that. Heck - you can do surround sound if you want it (assuming your program supports it).
disclaimer: this is what I have done and it's worked well for me for years. When I heard the improvement for the first time, there was no going back. Thus - I have absolutely no idea how good today's higher-end computer speakers sound
From the article: One key result to note, however, is that switching from any gray shade to black is the fastest of all. This is because switching to black simply requires that the voltage to the cell be set to maximum, and the cell responds quickly.
What the hell? Don't they mean the voltage is turned off to get black? Or maybe they're confusing it with white? I don't understand why you need power to produce black...
...unless they give it so much voltage that the thing responds quickly and pops - producing a gaping black hole in the cell's place.
When the user requests a web-page (which includes images and banners) the server checks whether the client also loads the banners.
How much do you want to bet that they'll use cookies to do this? You can't do it by IP address, for example, because of hosts using NAT. If you disable cookies, you're toast.
You're also pretty much screwed if you use Lynx as well, obviously.
Stopping a proxy from caching it, however, is probably just a matter of setting the Pragma/Expires HTTP headers. Not a 100% guarantee, but the polite proxies follow instructions.
I was quite serious about that post. I made it sound easy (and, well - it wasn't THAT hard). The hardest part was for that 8 months the work was more difficult. We had to implement nearly everything from scratch again, which was a bit of a pain (ie: replacing the working and debugged with new untested code).
The advantage, however, was that because we were effectively rewriting the application and phasing out the old one, we had the opportunity to not make the same mistakes that had been left in the old ASP/COM version of our program. What we lost in time porting the app we gained in program efficiency and ease of maintenance later (or, for us, now). Keep in mind that I stuck my neck out on the line - the bosses would have had my head had this plan backfired. This app was in production the entire time during the conversion - 100% uptime and new components were phased in over this period of time.
Before you start on anything like this, do take the time to carefully plan your approach (technologies, API layout, modularization, maintaining flexibility etc). I spent about a month's time planning how my team was going to solve this conversion project, and this time has paid off tenfold in the end. I can honestly say that we'd already have been dead had we stuck with the old model - the workload with the amount of staff we have, along with the relative unmaintainability and inflexibility of the old code (we're seeing a lot of demand for customization to our app), would have made it impossible to keep up. Properly designed modules made customization a breeze - simply extend a couple of classes and throw in custom code for that customer.
If you have more specific questions, I'd love to help give you some insight. Obviously I'd be under some NDA so I can't reveal exactly what our app does, but I can certainly point you in the right directions for accomplishing what you want to do. Send a note to arozeluk at home period com.
Rewriting is always an option. It's not a pretty one, but it CAN be done if you're dedicated enough.
Case in point - last year I saw the dead-end coming for my company's Enterprise solution, which was written in ASP/COM. The argument (er... *ahem*, discussion) I had with the higher-ups concluded that we HAD to continue moving forward. We couldn't wait 6 months for a rewrite (ambitious at best).
Fine, I said. Then let me do everything concurrently. Here's how it works:
Install Tomcat onto your Windows NT Server running IIS, along with JRE 1.3 and the HotSpot Server.
Link Tomcat in with IIS using the mod_isapi.dll you can get from the Tomcat site. Also install Tomcat as a service using jk_nt_service.exe.
Keep your Java session abstracted. The main session remains as-is within your ASP application. Write a bit of java.net code to hook in through a custom ASP page (note: security - ordinary clients can't access this page) to retrieve and update any session variables. This can be done by reading the ASPSESSION cookie, and spoofing it in your requests to IIS.
Any NEW components, write in Java. Remember - session variables get retrieved and saved from the ASP side still.
As you're working on new components, when you can arrange it, convert old components to Java one by one. Session still remains on ASP.
Wash, rinse, repeat until all components have been written in Java. Once this is done, convert your login into Java, and change your abstracted Session to be a Java session instead of hooking into IIS for the ASP one.
Voila. You are now 100% Java. Now get rid of IIS and switch to something else. This is the approach that my team took to rid ourselves of the VB horror that someone left me when I joined. It took about 8 months of solid effort, but it worked. We are now rid of all reliance on MS technologies from our site. We also managed to do it quickly because of good code layout, and the use of the most wonderful Velocity templates also available from the Jakarta site. This helped a lot.
The point is, you CAN do a rewrite. What you usually are NOT allowed to do is a code freeze. So... work around it! The beauty of this solution is that you are running two separate applications (technically) for a time. Keep a consistent look, and the users can't tell the difference between the ASP and the Java side. Change one function at a time, slowly, and eventually you'll reach the Utopia you're looking for.
The only time I've had to use cash was at Robins Donuts last week
You call yourself Canadian? Real Canadians get their donuts at Tim Hortons! Sheesh, eh?
Seriously, though, I'd like to see you try debit at McDonald's. Fortunately, Starbuck's takes debit, but there are a number of places that still do not. And yes, Timmy's is one of them too. So is my company's cafeteria (but at least they've got tabs, which IMO are better than debit).
There's another difference: Banks are LIABLE if they lose your information, which translates usually to you losing money.
Microsoft has never been accountable for anything being lost in the past, by hiding behind their EULA (ie: we are not responsible for any direct or indirect losses as a result of using this product. You agree not to sue us no matter what). Well, until Microsoft guarantees unconditionally that my information is SAFE, like the banks do, I will not ever, ever trust them.
There aren't any laws protecting me, so why should I even dip a toe into the water?
The puff a butterfly makes during flight will alter local weather a little, and this change will continue to influence in weather mechanics, until some months later this butterfly can originate an tornade on another continent.
If that's what a butterfly can do, I shudder at what might happen in Europe the next time I have a burrito for lunch!
I fart in your general direction! -Monty Python and the Holy Grail
Agreed - all of these template engines clearly have advantages and disadvantages.
My favourite parts of Velocity (and Webmacro, which inspired Velocity), and likely the other template engines, is that unlike with JSP I can use it to produce virtually anything I want. For example, currently I use Velocity templates on my production server to generate web pages, XML (for data transfer to customers and/or partners) and email notifications (by pumping the generated text out into whatever OutputStream I want, I can send it anywhere). When changes are needed, it's easy to implement, and often just a quick job in notepad does the trick. Plus, auto-reloading of templates is a huge bonus for me - Tomcat's automatic servlet reloading didn't work, but being able to change my templates on the fly has helped me a great deal when handling issues with our production box.
On the negative side, I didn't like Velocity's default configuration, which I found confusing when dealing with defined Macros (all macros you create in any template are declared in a global namespace by default, for example). This can be changed, however, by carefully reading the docs and writing your own configuration file.
I'm not familiar with Tea or FreeMarker, but I imagine they have similar capabilities.
why PHP is so popular when JSP provides a much more robust solution
Let's not forget that there are alternatives to JSP which might be even better to work with. I would strongly encourage you to check out Velocity.
Don't want to get into a religious war about this one, but I can say that when I was evaluating my company's Enterprise solution a few months ago, Velocity seemed to be more flexible and offered a better way to separate design from code. JSP suffers from the same things that haunt developers using ASP - it's much too easy to end up with dirty (extremely dirty) code after a few rounds of maintenance.
Any word on whether they support IIS integration like the 3.x line did (via mod_isapi.dll, which hooked into the ajp12 connector)? It was fantastic, and helped bridge my application while it was being rewritten into Java-only.
I can't seem to find any docs on how this might work, nor could I find any information on ajp12 at all in the 4.0 documentation! Now that the app has been rewritten (completely, finally) away from VB/asp to Java, it is possible to move to Apache (on any platform, since the code was carefully written to avoid platform-specific issues), but I'd still like to have the option of sticking with IIS at least for testing/benchmark comparison purposes...
The 3.x and 4.x trees are completely different codebases... My understanding is that the 3.x tree will continue to get a certain amount of maintenance
and development while the 4.x tree gets shaken out.
I know. Actually, 3.x was based on the Sun Java Server, whose source code was donated.
The irony is that it's taking longer for the 3.x line to get fixed properly than it is for the developers to have worked from scratch on a rewrite of the whole thing. There are quite a few things wrong with 3.2 which I won't get into (yes, we DO use it in production). I know that these things have been addressed in 4.0, while 3.3 is still working on it.
Anybody else appreciate the irony that 4.0 Final is released while 3.3 is still in beta?
I've been using Tomcat 3.2 in production for the last 6 months or so and it's been a wonderful servlet container. I can't wait to try out 4 in our testing environment!
Lucent has actually sold one of these such things - but you'll laugh when I tell you that their Cat5-to-802.11 adapter is actually a Wavelan card in a box. It's expensive, and fairly ridiculous to boot.
That'd be more or less what I'd expect anyway. It'd be useful, but only if they can get it to be easy to use for non-technical folks. People who can either plug the wire in or plug the box in, and voila, they're connected. DHCP ought to be able to handle the rest.
You obviously have no idea how much complexity is invlolved in 802.11b. No solution for 802.11b works without a pc to controll it. In the case of the client card it is obvious, its your pc with a driver that does the work. In the case of a base station or access point there is a pc (embedded) that controlls the communications. There is no way to make a generic, small media adapter for 802.11b at this time. After a few more revs of miniturization there might be, but I doubt it as there is a limit to how small things like the antenna and the rf components can get.
So embed a pc in there. I never said I was concerned about cost. Nor did I ever say that it had to be smaller than a PC card. You can get an embedded PC in something as small as a SIMM. so size isn't a concern for me. What I wanted was something that was flexible, perhaps the size of a Palm Pilot or less, which could handle that sort of thing. I never said it was a simple device, but that's something that the hardware can address, and it need not be my problem then. Remember, Joe User doesn't WANT to have to care how complex 802.11b is - he just wants it to work when he plugs it in.
Perhaps it might be better if a hardware company could come out with an adapter.
Instead of having the wireless hardware built into the card, wouldn't it be nice if someone came up with a way to just use a regular ethernet card, and plug in sort of a 'wireless adapter dongle' into it instead of your cat5?
That way, the same card could be used for both, plus the adapter could be made to work with any card. Perhaps this sort of hardware solution could be OS-independent as well...
Why buy this when there's a hacking solution to the problem? I thought of this years ago.
Case in point: I was suffering from a case of RSI some years ago (before I figured out how the height of my chair and mousepad affected my wrists). My wrists were killing me every time I reached for the mouse.
The solution? A 50-line program written in C that (in Windows, sorry - my OS of choice at the time) polled my joystick, and translated its commands to the mouse pointer. Button 1 became 'click'. Button 2 became the left mouse button, and I linked Button 3 to 'double click'. Took me about an hour to whip up the program, and then I used it for about a month before my injury subsided and I was able to buy a better chair and adjust my desk height properly. It worked well, and it didn't cost me anything other than a smidge of time.
It made everything feel like a video game, though, so that was a bit weird. I've probably still got the program in my archives, but I'm at work and the file's at home somewhere.
Somebody posted a link to an older version (2000B). I've got 2000C, the latest version, just uploaded to my GeoCities account that I haven't used in years:)
Go nuts! Both the source and RPM version are there (you might need to go easy, though... GeoCities has some crappy transfer limits)
If anybody wants to get a copy directly from me (if GeoCities get/.d or something), email me at necrotech at geocities period com and I can arrange to transfer it to you.
It wasn't too difficult to register a.ca domain name, if you knew which buttons to push.
I registered 2 of them. Basically, the requirements were:
1 - You needed to have a trademark registered or some other proof that the name you're registering resembles your business name
2 - Domain name cannot be the name of a city/province/territory (ie: cannot register toronto.ca)
3 - You needed to have a presence in multiple provinces to have a.ca-level name. Otherwise, your domain would fall under the province code's domain (ie: mydomain.on.ca if I'm in Ontario). If you are a tiny little business with presence in only one city, then you had to take the city name with it (ie: mydomain.toronto.on.ca).
It wasn't THAT hard... and yes, I did manage to get a.ca domain (without city and province in it), and it only took 2 weeks (because yes, the requests were reviewed by hand). The bonus for putting up with the red tape was that the whole thing didn't cost you a penny - the domain names were free. Now, sadly, they are not.
Meta Moderation received an overall at the maniacal hands of Cliff.
User Info pages were handed a pair of old jeans with patches over the holes in the knees, and the 2-million-odd old articles were collectively given a large flowery muumuu.
Security gets a brand-new pair of underwear with an attached padlock.
Slashdot Mirror
Any idea of we'll be seeing a compatible implementation of something that can do everything Outlook can do (including connecting to an Exchange server)? I don't mean just email, but I mean Calendar, Tasks, Contacts booking meetings etc.
As soon as I can get something that would replace this one last piece, then I can switch away from Windows in my company (as I have at home). Unfortunately, the company relies very much on Outlook's functionality, and will not move away from Exchange server, so if I want to move it's up to me to find and install a compatible alternative, but so compatible that the REST of the users can stay on Outlook if they choose to.
In my opinion, this is one thing that any true Office suite needs before MS-Office can be truly replaced. As buggy and insecure as Outlook is, it organizes the company that I work for, and it can not be removed from my desktop until a fully compatible replacement is available. It's the one last thing that ties me to Windows.
Why use 'computer speakers' at all? If you're going to spend some cash, just get a Y-cable and hook your computer up to your stereo receiver's AUX input.
This is the best way (IMO) to get decent sound, and of course, this gives you things like radio, tape decks, equalizer and whatever else you want to add to it. Add a subwoofer to that. Heck - you can do surround sound if you want it (assuming your program supports it).
disclaimer: this is what I have done and it's worked well for me for years. When I heard the improvement for the first time, there was no going back. Thus - I have absolutely no idea how good today's higher-end computer speakers sound
From the article: One key result to note, however, is that switching from any gray shade to black is the fastest of all. This is because switching to black simply requires that the voltage to the cell be set to maximum, and the cell responds quickly.
What the hell? Don't they mean the voltage is turned off to get black? Or maybe they're confusing it with white? I don't understand why you need power to produce black...
...unless they give it so much voltage that the thing responds quickly and pops - producing a gaping black hole in the cell's place.
When the user requests a web-page (which includes images and banners) the server checks whether the client also loads the banners.
How much do you want to bet that they'll use cookies to do this? You can't do it by IP address, for example, because of hosts using NAT. If you disable cookies, you're toast.
You're also pretty much screwed if you use Lynx as well, obviously.
Stopping a proxy from caching it, however, is probably just a matter of setting the Pragma/Expires HTTP headers. Not a 100% guarantee, but the polite proxies follow instructions.
Heh - you beat me to it! Good job!
I was quite serious about that post. I made it sound easy (and, well - it wasn't THAT hard). The hardest part was for that 8 months the work was more difficult. We had to implement nearly everything from scratch again, which was a bit of a pain (ie: replacing the working and debugged with new untested code).
The advantage, however, was that because we were effectively rewriting the application and phasing out the old one, we had the opportunity to not make the same mistakes that had been left in the old ASP/COM version of our program. What we lost in time porting the app we gained in program efficiency and ease of maintenance later (or, for us, now). Keep in mind that I stuck my neck out on the line - the bosses would have had my head had this plan backfired. This app was in production the entire time during the conversion - 100% uptime and new components were phased in over this period of time.
Before you start on anything like this, do take the time to carefully plan your approach (technologies, API layout, modularization, maintaining flexibility etc). I spent about a month's time planning how my team was going to solve this conversion project, and this time has paid off tenfold in the end. I can honestly say that we'd already have been dead had we stuck with the old model - the workload with the amount of staff we have, along with the relative unmaintainability and inflexibility of the old code (we're seeing a lot of demand for customization to our app), would have made it impossible to keep up. Properly designed modules made customization a breeze - simply extend a couple of classes and throw in custom code for that customer.
If you have more specific questions, I'd love to help give you some insight. Obviously I'd be under some NDA so I can't reveal exactly what our app does, but I can certainly point you in the right directions for accomplishing what you want to do. Send a note to arozeluk at home period com.
Rewriting is always an option. It's not a pretty one, but it CAN be done if you're dedicated enough.
Case in point - last year I saw the dead-end coming for my company's Enterprise solution, which was written in ASP/COM. The argument (er... *ahem*, discussion) I had with the higher-ups concluded that we HAD to continue moving forward. We couldn't wait 6 months for a rewrite (ambitious at best).
Fine, I said. Then let me do everything concurrently. Here's how it works:
Install Tomcat onto your Windows NT Server running IIS, along with JRE 1.3 and the HotSpot Server.
Link Tomcat in with IIS using the mod_isapi.dll you can get from the Tomcat site. Also install Tomcat as a service using jk_nt_service.exe.
Keep your Java session abstracted. The main session remains as-is within your ASP application. Write a bit of java.net code to hook in through a custom ASP page (note: security - ordinary clients can't access this page) to retrieve and update any session variables. This can be done by reading the ASPSESSION cookie, and spoofing it in your requests to IIS.
Any NEW components, write in Java. Remember - session variables get retrieved and saved from the ASP side still.
As you're working on new components, when you can arrange it, convert old components to Java one by one. Session still remains on ASP.
Wash, rinse, repeat until all components have been written in Java. Once this is done, convert your login into Java, and change your abstracted Session to be a Java session instead of hooking into IIS for the ASP one.
Voila. You are now 100% Java. Now get rid of IIS and switch to something else. This is the approach that my team took to rid ourselves of the VB horror that someone left me when I joined. It took about 8 months of solid effort, but it worked. We are now rid of all reliance on MS technologies from our site. We also managed to do it quickly because of good code layout, and the use of the most wonderful Velocity templates also available from the Jakarta site. This helped a lot.
The point is, you CAN do a rewrite. What you usually are NOT allowed to do is a code freeze. So... work around it! The beauty of this solution is that you are running two separate applications (technically) for a time. Keep a consistent look, and the users can't tell the difference between the ASP and the Java side. Change one function at a time, slowly, and eventually you'll reach the Utopia you're looking for.
The only time I've had to use cash was at Robins Donuts last week
You call yourself Canadian? Real Canadians get their donuts at Tim Hortons! Sheesh, eh?
Seriously, though, I'd like to see you try debit at McDonald's. Fortunately, Starbuck's takes debit, but there are a number of places that still do not. And yes, Timmy's is one of them too. So is my company's cafeteria (but at least they've got tabs, which IMO are better than debit).
There's another difference: Banks are LIABLE if they lose your information, which translates usually to you losing money.
Microsoft has never been accountable for anything being lost in the past, by hiding behind their EULA (ie: we are not responsible for any direct or indirect losses as a result of using this product. You agree not to sue us no matter what). Well, until Microsoft guarantees unconditionally that my information is SAFE, like the banks do, I will not ever, ever trust them.
There aren't any laws protecting me, so why should I even dip a toe into the water?
The puff a butterfly makes during flight will alter local weather a little, and this change will continue to influence in weather mechanics, until some months later this butterfly can originate an tornade on another continent.
If that's what a butterfly can do, I shudder at what might happen in Europe the next time I have a burrito for lunch!
I fart in your general direction! -Monty Python and the Holy Grail
Agreed - all of these template engines clearly have advantages and disadvantages.
My favourite parts of Velocity (and Webmacro, which inspired Velocity), and likely the other template engines, is that unlike with JSP I can use it to produce virtually anything I want. For example, currently I use Velocity templates on my production server to generate web pages, XML (for data transfer to customers and/or partners) and email notifications (by pumping the generated text out into whatever OutputStream I want, I can send it anywhere). When changes are needed, it's easy to implement, and often just a quick job in notepad does the trick. Plus, auto-reloading of templates is a huge bonus for me - Tomcat's automatic servlet reloading didn't work, but being able to change my templates on the fly has helped me a great deal when handling issues with our production box.
On the negative side, I didn't like Velocity's default configuration, which I found confusing when dealing with defined Macros (all macros you create in any template are declared in a global namespace by default, for example). This can be changed, however, by carefully reading the docs and writing your own configuration file.
I'm not familiar with Tea or FreeMarker, but I imagine they have similar capabilities.
why PHP is so popular when JSP provides a much more robust solution
Let's not forget that there are alternatives to JSP which might be even better to work with. I would strongly encourage you to check out Velocity.
Don't want to get into a religious war about this one, but I can say that when I was evaluating my company's Enterprise solution a few months ago, Velocity seemed to be more flexible and offered a better way to separate design from code. JSP suffers from the same things that haunt developers using ASP - it's much too easy to end up with dirty (extremely dirty) code after a few rounds of maintenance.
Any word on whether they support IIS integration like the 3.x line did (via mod_isapi.dll, which hooked into the ajp12 connector)? It was fantastic, and helped bridge my application while it was being rewritten into Java-only.
I can't seem to find any docs on how this might work, nor could I find any information on ajp12 at all in the 4.0 documentation! Now that the app has been rewritten (completely, finally) away from VB/asp to Java, it is possible to move to Apache (on any platform, since the code was carefully written to avoid platform-specific issues), but I'd still like to have the option of sticking with IIS at least for testing/benchmark comparison purposes...
The 3.x and 4.x trees are completely different codebases... My understanding is that the 3.x tree will continue to get a certain amount of maintenance
and development while the 4.x tree gets shaken out.
I know. Actually, 3.x was based on the Sun Java Server, whose source code was donated.
The irony is that it's taking longer for the 3.x line to get fixed properly than it is for the developers to have worked from scratch on a rewrite of the whole thing. There are quite a few things wrong with 3.2 which I won't get into (yes, we DO use it in production). I know that these things have been addressed in 4.0, while 3.3 is still working on it.
Anybody else appreciate the irony that 4.0 Final is released while 3.3 is still in beta?
I've been using Tomcat 3.2 in production for the last 6 months or so and it's been a wonderful servlet container. I can't wait to try out 4 in our testing environment!
Lucent has actually sold one of these such things - but you'll laugh when I tell you that their Cat5-to-802.11 adapter is actually a Wavelan card in a box. It's expensive, and fairly ridiculous to boot.
That'd be more or less what I'd expect anyway. It'd be useful, but only if they can get it to be easy to use for non-technical folks. People who can either plug the wire in or plug the box in, and voila, they're connected. DHCP ought to be able to handle the rest.
What was involved in booting the thing?
You obviously have no idea how much complexity is invlolved in 802.11b. No solution for 802.11b works without a pc to controll it. In the case of the client card it is obvious, its your pc with a driver that does the work. In the case of a base station or access point there is a pc (embedded) that controlls the communications. There is no way to make a generic, small media adapter for 802.11b at this time. After a few more revs of miniturization there might be, but I doubt it as there is a limit to how small things like the antenna and the rf components can get.
So embed a pc in there. I never said I was concerned about cost. Nor did I ever say that it had to be smaller than a PC card. You can get an embedded PC in something as small as a SIMM. so size isn't a concern for me. What I wanted was something that was flexible, perhaps the size of a Palm Pilot or less, which could handle that sort of thing. I never said it was a simple device, but that's something that the hardware can address, and it need not be my problem then. Remember, Joe User doesn't WANT to have to care how complex 802.11b is - he just wants it to work when he plugs it in.
Perhaps it might be better if a hardware company could come out with an adapter.
Instead of having the wireless hardware built into the card, wouldn't it be nice if someone came up with a way to just use a regular ethernet card, and plug in sort of a 'wireless adapter dongle' into it instead of your cat5?
That way, the same card could be used for both, plus the adapter could be made to work with any card. Perhaps this sort of hardware solution could be OS-independent as well...
That sucks.
Why buy this when there's a hacking solution to the problem? I thought of this years ago.
Case in point: I was suffering from a case of RSI some years ago (before I figured out how the height of my chair and mousepad affected my wrists). My wrists were killing me every time I reached for the mouse.
The solution? A 50-line program written in C that (in Windows, sorry - my OS of choice at the time) polled my joystick, and translated its commands to the mouse pointer. Button 1 became 'click'. Button 2 became the left mouse button, and I linked Button 3 to 'double click'. Took me about an hour to whip up the program, and then I used it for about a month before my injury subsided and I was able to buy a better chair and adjust my desk height properly. It worked well, and it didn't cost me anything other than a smidge of time.
It made everything feel like a video game, though, so that was a bit weird. I've probably still got the program in my archives, but I'm at work and the file's at home somewhere.
Somebody posted a link to an older version (2000B). I've got 2000C, the latest version, just uploaded to my GeoCities account that I haven't used in years :)
/.d or something), email me at necrotech at geocities period com and I can arrange to transfer it to you.
Go nuts! Both the source and RPM version are there (you might need to go easy, though... GeoCities has some crappy transfer limits)
If anybody wants to get a copy directly from me (if GeoCities get
It wasn't too difficult to register a .ca domain name, if you knew which buttons to push.
.ca-level name. Otherwise, your domain would fall under the province code's domain (ie: mydomain.on.ca if I'm in Ontario). If you are a tiny little business with presence in only one city, then you had to take the city name with it (ie: mydomain.toronto.on.ca).
.ca domain (without city and province in it), and it only took 2 weeks (because yes, the requests were reviewed by hand). The bonus for putting up with the red tape was that the whole thing didn't cost you a penny - the domain names were free. Now, sadly, they are not.
I registered 2 of them. Basically, the requirements were:
1 - You needed to have a trademark registered or some other proof that the name you're registering resembles your business name
2 - Domain name cannot be the name of a city/province/territory (ie: cannot register toronto.ca)
3 - You needed to have a presence in multiple provinces to have a
It wasn't THAT hard... and yes, I did manage to get a
apt-get remove recession
Since IBM is more likely to be supporting Red Hat, the appropriate command might look more like:
rpm --uninstall --allmatches recession
Seven nines of uptime is 315 seconds a year. I think you mean nine nines of uptime. Or maybe you mean seven nines after the decimal.
Hmm...
60 seconds * 60 minutes * 24 hours * 365 days = 31536000
99.99999% of that is (0.9999999 * 31536000) = 31535996.8464
31536000 - 3153996.8464 = 3.1536 seconds
Or the quicker way: (60*60*24*365 * 0.0000001 = 3.1536)
Looks like you forgot your decimal place somewhere.
I think it'd make a great accessory to the Jeep TJ I'm planning to buy soon :)
Meta Moderation received an overall at the maniacal hands of Cliff.
User Info pages were handed a pair of old jeans with patches over the holes in the knees, and the 2-million-odd old articles were collectively given a large flowery muumuu.
Security gets a brand-new pair of underwear with an attached padlock.