It made me wonder who, thousands of years ago, thought about the concept of tranquility and decided that the lower radical should be the symbol for "woman."
After the umpteenth million time of not being able to build VMware Server under the latest kernel version, and this time NOT being able to find yet-another-vmware-any patch to fix it, I finally abandoned VMware (at least for personal use) and switched back to VirtualBox.
Amen. I never figured out why VMware didn't put a little effort into porting its modules to more recent kernel versions. (AFAIK, all the vmware-any-any releases were put out by Petr Vandrovec, a VMware employee. I don't know why he stopped, but he has my thanks for providing a useful service for all these years.)
Like you, I grew tired of struggling with the modules, and hopped over to VirtualBox. My experience so far has been somewhat mitigated; the basic functionality is there, but there's a certain lack of "polish" and I was hit by couple of bugs (ie. serial didn't work right; VB complains about a non-existent mounted device). Still, it mostly works for me, and I'm looking forward to see it mature further.
I will be interested in seeing how it works with USB.
You were probably aware of this, but USB support is not included in the Open Source Edition. (This is probably what I'll miss most from VMware Workstation.)
I only use it to download repositories because I'm not really much of a programmer.
I assume you do a simple "git clone <url>", then? Did you use --depth or any other option?
Suffice to say that it has happened to me personally on at least two occasions, back when I was a modem user and had lots of communications problems.
Was this a long time ago? Git has matured a lot since its infant years (2005-2006).
I've had git shit itself on me a couple times, so obviously they don't have it right.
From what I've seen of the Git development team, I'm sure they would be eager to correct such a flaw.
If I understand you correctly, you would run git-clone, and lose the connection in the process? This would leave you with an incomplete directory, and running git-fetch in it would fail?
If git craps in the middle of initially fetching a repo it can corrupt itself.
I'm curious, could you provide some details on this? The way that git operates, fetching objects individually, I find it dubious that it would fail like that.
svn is the only SCM that seems to have ANY ability to recover from a fault.
You're kidding, right?
I remember when I switched from CVS to SVN[*]. On more than one occasion, while importing my old work, svn would just choke and die, claiming there was something wrong within my.svn directory. At that point, I had to nuke the working directory and checkout a fresh copy.
Obviously, no data was ever lost (since it was only the working copy that was hosed), but it made me seriously doubt Subversion's ability not to screw up its black box database.
[*] Not too many years ago -- this must've been around SVN 1.3.
Sadly, bell got the right to slow down their resellers lines when they detected p2p stuff on it.
If you're with TekSavvy, all you need to do is set up a Multilink (also known as Multipath) PPPoE connection, which fools Bell's equipment and defeats their throttle.
(Obviously, this is a temporary solution, but I doubt that Bell will spend much effort to plug that hole in the near future.)
To be fair, fluxbox workspaces are the equivalent of E's multiple desktops; I don't think it has anything matching E's virtual desktops. (And yes, I do miss those sometimes.) There is therefore no edge flipping, although moving a window past the edge will move to the next workspace.
As for pagers, there is at least one out there (fbpager), but I found I didn't need a pager as much as I did with E. With a middle-click, I can pull a list of all workspaces, and all windows in any of them (similar to E, if I recall). Most importantly, the "Send To" command makes it easy to send a window to another workspace. Also, you could have the (optional) taskbar display all windows, instead of only those in the current workspace.
* It's fast. Very fast. * It feels clean and simple. * Looks very good. * Very customisable. * Keyboard shortcuts for just about anything! * Just about everything can be controlled or configured from the command prompt.
Apart from that last point, the same could be said about fluxbox.
I myself migrated from E to fluxbox a few months ago, and found it to have that same no-frills attitude. (Or rather, just-the-frills-you-want-and-nothing-else.) From what I gather, Blackbox and its offspring appear to have filled the void left by E16 rotting away and E17 never releasing.
I too am a happy Tuffmail customer. What won me over was the ability to configure MX restrictions to my heart's desire. (Want to enforce all RFCs? Or block most of Asia? It's your choice to make.) I didn't find any other provider that even came close to this.
While the RAM itself still runs at 200 MHz (which was the point of DDR2), the I/O is indeed clocked at 400 MHz. Thus, a CAS latency of 2 cycles would equal 5ns.
you're forgetting that timings are measured in clock cycles. Right.
3-4-4 DDR2 (assuming it's at least DDR2-800 a.k.a PC-6400) has lower latency than your precious 2-2-2 DDR. Wrong.
DDR-400 (PC-3200) and DDR2-800 (PC-6400) are both running on the same 200 MHz clock. A CAS latency of 2 cycles at this speed equals 10ns, regardless of how many transfers are taking place in one clock cycle.
when you bought a 486 computer, the RAM and Processor were running essentially at the same speed Not in the case of a DX/2 or DX/4, they weren't.
the cpu never hit cycles where the ram couldn't keep up with cached data and would miss a cycle for the want of data The CPU has always hit wait cycles, because RAM has always been slower than we would've liked. You think that your non-EDO 100ns DRAM was magically keeping pace with your 486 just because it was on a 40MHz bus? Why do you think Intel went to the trouble of putting a L1 cache on that chip?
(I for one distinctly remember wait states BIOS settings for my 386SX-16, and we're talking about a CPU that was as slow as molasses.)
But every new system, from the Pentium 1 on up ram has gotten slower and slower than the CPU Ironically enough, if I'm reading this chart correctly, the Pentium 60 and 66 would appear to be the only points in the x86 timeline where there was RAM available that could keep pace with the CPU, at least in bursts.
yet the crazy computer scientists keep making it worse by engineering for 'burst' mode rather than latency. The same could be said about disk drives, and seek times vs. throughput. It should be obvious that both are the result of physical limitations, and are not likely to go away any time soon.
Everything hits DVDs eventually, In the US? Sure, I guess. (Although, where's my Daria box set?)
Once you move on to smaller markets, however, DVD distribution becomes less profitable, especially for older series (where royalties can be problematic).
Of all the TV I once taped on VHS, almost every American show is now available on DVD, while almost no local show is. (It is getting better for newer series, though.)
The problem is not that 'television is awful', the problem is that you have nothing else you'd rather be doing. Since I don't have any mod points, I'll just say it out loud: this was the most insightful take I've heard on the whole "TV == shit" thread. Thank you.
Re:This is actually untrue
on
Ethics In IT
·
· Score: 1
When I was a general manager, one of my policies was always to pay the small suppliers promptly, because they need it most. That's not only ethics, it is simple common sense. Sadly, Jack Tramiel showed that the opposite could be quite profitable.
(For those who don't know, Tramiel had a policy of starving his small suppliers for cash, pushing them into debt/brankruptcy, and then buying them on the cheap. It was this vertical integration that allowed Commodore to do its magic in the 1980s.)
There are 2^16 port numbers, but there are no theoretical limits on the number of connections incoming to a single port. Actually, given that IP has a finite address space, there is a theoretical limit: 2^48 connections for IPv4, and 2^144 for IPv6.
That was the most insightful MySQL comment I've read for quite a while. Thanks!
If you're still around, here's one comment and one question:
Even worse, the hard-coded queries contain many MySQL-isms (MySQL specific syntax) and depend on MySQL behaviors, like the idea that there's a date 0000-00-00 00:00:00. This seems like a bad example, as it's something that can be gradually phased out with no interruption of service. It'd be nice to see an example of something that has to be converted in one fell swoop.
They have native UUID/GUID field types rather than using VARCHAR, which is huge for us. I'm curious: what is the big advantage over a plain CHAR(32) or CHAR(16) BINARY field?
This absolutely retarded convention should have disappeared with the Genesis and SNES. Thank you. You took the words right out of my mouth.
I'm currently playing Metroid Prime 2, and the lack of convenient save points is really starting to piss me off. (At one point, a previously accessible save point is removed prior to a boss battle. Someone at Retro Studios deserves to die for this.)
Two days ago, I was playing Twilight Princess and going through the Cave of Ordeals, which consists of 45 successive fights with no possibility of saving. The only way I could take a break was to pause the game and leave the GameCube running, just like we used to do 20 years ago. That's how far we've come.
(What's sad is that we've already left this behind for portable consoles, and people have come to expect to be able to turn off their DS at a moment's notice. Why can't we do the same for regular consoles?)
Taking this one step further, I wonder if we shouldn't just do away with the whole notion of "game over". It made sense back when we were pumping quarters into a Galaga machine at the arcade, but what purpose does it serve in this day an age? All it does is force me to relive the past five minutes of my life to get to the exact same point where I was before. Isn't there a better way to make games challenging beyond what is little more than a reset button?
Are you looking for eval BLOCK around the chained method calls?
No, it's just the undef case that I want to handle differently. What happens is that I'm chaining several method calls that return either an object or undef. So, for example, I want to test $me->boss->wife->is_cute() while accounting for the possibility of unemployment or celibacy. This will either turn into an ugly one-liner with lots of "&&" and redundant calls, or the use of temporary variables.
I guess I'm wishing for some sort of auto-vivification similar to what is done for arrays and hashes.
My own desperate solution was to create a small class that returns undef via AUTOLOAD, as well as a function that creates such an instance if its argument is undefined. This results in something like u(u($me->boss)->wife)->is_cute() which, albeit unappealing, is at least somewhat bearable.
(Although, given the apparent lack of such a feature in any OO language I know, I do sometimes wonder if I'm being silly.)
I would bet that most Perl programs/modules will exhibit erratic behavior when supplied "0" as an argument, due to the common use of "||" or "||=" to provide default values. Although "//" may not be earth-shattering, it certainly has a purpose.
(Me, I'm still waiting for the "call a method on this object if defined" operator. Oh, how I long for "$foo->bar()->baz()" not to fail if bar() returns undef...)
- all white mages (how the hell do you do damage??)
With HARM, FADE, and a lot of patience while your characters repeatedly swing their tiny rubber mallet. Fortunately, it gets somewhat easier in the second half of the game, once you find items that allow you to cast a little bit of black magic.
I myself beat FF1 with four white mages/wizards, at level 50, with the added restriction that I did not let a single character die. (I may have allowed myself to suffer death if I could flee afterwards — the goal was to keep everyone at the same XP.) Fighting Astos was a b*tch, as it was a race to MUTE him before he could kill one of mine. I must have hit Reset a dozen times before I could beat him.
(Nowadays, I try not to think about what would have happened had I spent all this time doing something useful with my life. -sigh-)
I gotta remember to pull up the clip where Rob Corddry was "exit-polling Covenant aliens". Or was that one released on DVD?
Yes, that scene was part of their live election-night coverage (Indecision 2004: Prelude to a Recount), which is included in the Indecision 2004 DVD set.
I'm curious: what backup method are you guys currently using to store those hundreds of GB? DVDs just don't cut it anymore, and tape drives beyond DDS-4 (20 GB) are quite expensive. What's left? USB hard drives?
No, Volatile is _not_ the normal update stream. When the US decided to update DS volatile was not even considered as an option,
That's because volatile was not an official part of Debian prior to the etch release; security updates were the only way to push new versions back then.
The only question I have is why on _earth_ the safe (and standards-compliant) mode isn't the default, with the weird MySQL-only accept-Feb-30-as-a-valid-date kind of behaviour enabled with a special option for those who really want it.
Actually, according to the documentation pointed to by the GP:
As of 5.0.2, the server requires that month and day values be legal, and not merely in the range 1 to 12 and 1 to 31, respectively. With strict mode disabled, invalid dates such as '2004-04-31' are converted to '0000-00-00' and a warning is generated. With strict mode enabled, invalid dates generate an error.
Slashdot Mirror
It is indeed part of POSIX; see XCU 2.5.2 for a complete list of such variables.
(A bit late for a reply, but still.)
You might be interested in Kenneth Henshall's explanation about the colorful origin of this character.
(Unfortunately, this is very atypical of kanji/hanzi — most of them are quite boring, which doesn't help at all when it comes to memorizing them.)
After the umpteenth million time of not being able to build VMware Server under the latest kernel version, and this time NOT being able to find yet-another-vmware-any patch to fix it, I finally abandoned VMware (at least for personal use) and switched back to VirtualBox.
Amen. I never figured out why VMware didn't put a little effort into porting its modules to more recent kernel versions. (AFAIK, all the vmware-any-any releases were put out by Petr Vandrovec, a VMware employee. I don't know why he stopped, but he has my thanks for providing a useful service for all these years.)
Like you, I grew tired of struggling with the modules, and hopped over to VirtualBox. My experience so far has been somewhat mitigated; the basic functionality is there, but there's a certain lack of "polish" and I was hit by couple of bugs (ie. serial didn't work right; VB complains about a non-existent mounted device). Still, it mostly works for me, and I'm looking forward to see it mature further.
I will be interested in seeing how it works with USB.
You were probably aware of this, but USB support is not included in the Open Source Edition. (This is probably what I'll miss most from VMware Workstation.)
I assume you do a simple "git clone <url>", then? Did you use --depth or any other option?
Was this a long time ago? Git has matured a lot since its infant years (2005-2006).
From what I've seen of the Git development team, I'm sure they would be eager to correct such a flaw.
If I understand you correctly, you would run git-clone, and lose the connection in the process? This would leave you with an incomplete directory, and running git-fetch in it would fail?
I'm curious, could you provide some details on this? The way that git operates, fetching objects individually, I find it dubious that it would fail like that.
You're kidding, right?
I remember when I switched from CVS to SVN[*]. On more than one occasion, while importing my old work, svn would just choke and die, claiming there was something wrong within my .svn directory. At that point, I had to nuke the working directory and checkout a fresh copy.
Obviously, no data was ever lost (since it was only the working copy that was hosed), but it made me seriously doubt Subversion's ability not to screw up its black box database.
[*] Not too many years ago -- this must've been around SVN 1.3.
If you're with TekSavvy, all you need to do is set up a Multilink (also known as Multipath) PPPoE connection, which fools Bell's equipment and defeats their throttle.
(Obviously, this is a temporary solution, but I doubt that Bell will spend much effort to plug that hole in the near future.)
To be fair, fluxbox workspaces are the equivalent of E's multiple desktops; I don't think it has anything matching E's virtual desktops. (And yes, I do miss those sometimes.) There is therefore no edge flipping, although moving a window past the edge will move to the next workspace.
As for pagers, there is at least one out there (fbpager), but I found I didn't need a pager as much as I did with E. With a middle-click, I can pull a list of all workspaces, and all windows in any of them (similar to E, if I recall). Most importantly, the "Send To" command makes it easy to send a window to another workspace. Also, you could have the (optional) taskbar display all windows, instead of only those in the current workspace.
Apart from that last point, the same could be said about fluxbox.
I myself migrated from E to fluxbox a few months ago, and found it to have that same no-frills attitude. (Or rather, just-the-frills-you-want-and-nothing-else.) From what I gather, Blackbox and its offspring appear to have filled the void left by E16 rotting away and E17 never releasing.
I too am a happy Tuffmail customer. What won me over was the ability to configure MX restrictions to my heart's desire. (Want to enforce all RFCs? Or block most of Asia? It's your choice to make.) I didn't find any other provider that even came close to this.
While the RAM itself still runs at 200 MHz (which was the point of DDR2), the I/O is indeed clocked at 400 MHz. Thus, a CAS latency of 2 cycles would equal 5ns.
Thanks for setting me straight.
DDR-400 (PC-3200) and DDR2-800 (PC-6400) are both running on the same 200 MHz clock. A CAS latency of 2 cycles at this speed equals 10ns, regardless of how many transfers are taking place in one clock cycle.
(I for one distinctly remember wait states BIOS settings for my 386SX-16, and we're talking about a CPU that was as slow as molasses.) But every new system, from the Pentium 1 on up ram has gotten slower and slower than the CPU Ironically enough, if I'm reading this chart correctly, the Pentium 60 and 66 would appear to be the only points in the x86 timeline where there was RAM available that could keep pace with the CPU, at least in bursts. yet the crazy computer scientists keep making it worse by engineering for 'burst' mode rather than latency. The same could be said about disk drives, and seek times vs. throughput. It should be obvious that both are the result of physical limitations, and are not likely to go away any time soon.
Once you move on to smaller markets, however, DVD distribution becomes less profitable, especially for older series (where royalties can be problematic).
Of all the TV I once taped on VHS, almost every American show is now available on DVD, while almost no local show is. (It is getting better for newer series, though.)
(For those who don't know, Tramiel had a policy of starving his small suppliers for cash, pushing them into debt/brankruptcy, and then buying them on the cheap. It was this vertical integration that allowed Commodore to do its magic in the 1980s.)
If you're still around, here's one comment and one question: Even worse, the hard-coded queries contain many MySQL-isms (MySQL specific syntax) and depend on MySQL behaviors, like the idea that there's a date 0000-00-00 00:00:00. This seems like a bad example, as it's something that can be gradually phased out with no interruption of service. It'd be nice to see an example of something that has to be converted in one fell swoop. They have native UUID/GUID field types rather than using VARCHAR, which is huge for us. I'm curious: what is the big advantage over a plain CHAR(32) or CHAR(16) BINARY field?
This absolutely retarded convention should have disappeared with the Genesis and SNES. Thank you. You took the words right out of my mouth.
I'm currently playing Metroid Prime 2, and the lack of convenient save points is really starting to piss me off. (At one point, a previously accessible save point is removed prior to a boss battle. Someone at Retro Studios deserves to die for this.)
Two days ago, I was playing Twilight Princess and going through the Cave of Ordeals, which consists of 45 successive fights with no possibility of saving. The only way I could take a break was to pause the game and leave the GameCube running, just like we used to do 20 years ago. That's how far we've come.
(What's sad is that we've already left this behind for portable consoles, and people have come to expect to be able to turn off their DS at a moment's notice. Why can't we do the same for regular consoles?)
Taking this one step further, I wonder if we shouldn't just do away with the whole notion of "game over". It made sense back when we were pumping quarters into a Galaga machine at the arcade, but what purpose does it serve in this day an age? All it does is force me to relive the past five minutes of my life to get to the exact same point where I was before. Isn't there a better way to make games challenging beyond what is little more than a reset button?
No, it's just the undef case that I want to handle differently. What happens is that I'm chaining several method calls that return either an object or undef. So, for example, I want to test $me->boss->wife->is_cute() while accounting for the possibility of unemployment or celibacy. This will either turn into an ugly one-liner with lots of "&&" and redundant calls, or the use of temporary variables.
I guess I'm wishing for some sort of auto-vivification similar to what is done for arrays and hashes.
My own desperate solution was to create a small class that returns undef via AUTOLOAD, as well as a function that creates such an instance if its argument is undefined. This results in something like u(u($me->boss)->wife)->is_cute() which, albeit unappealing, is at least somewhat bearable.
(Although, given the apparent lack of such a feature in any OO language I know, I do sometimes wonder if I'm being silly.)
P.S.: Thanks for making Perl testing fun!
I would bet that most Perl programs/modules will exhibit erratic behavior when supplied "0" as an argument, due to the common use of "||" or "||=" to provide default values. Although "//" may not be earth-shattering, it certainly has a purpose.
(Me, I'm still waiting for the "call a method on this object if defined" operator. Oh, how I long for "$foo->bar()->baz()" not to fail if bar() returns undef...)
With HARM, FADE, and a lot of patience while your characters repeatedly swing their tiny rubber mallet. Fortunately, it gets somewhat easier in the second half of the game, once you find items that allow you to cast a little bit of black magic.
I myself beat FF1 with four white mages/wizards, at level 50, with the added restriction that I did not let a single character die. (I may have allowed myself to suffer death if I could flee afterwards — the goal was to keep everyone at the same XP.) Fighting Astos was a b*tch, as it was a race to MUTE him before he could kill one of mine. I must have hit Reset a dozen times before I could beat him.
(Nowadays, I try not to think about what would have happened had I spent all this time doing something useful with my life. -sigh-)