Because that's when all the programmers pump out their best work. Since programmers are the most important group of people currently inhabiting this desolate rock, all others should be punished for their ignorance. Therefore it will happen during the day.
I disagree. Views are very very helpful in many cases - for example, when you need a join between >1 table to get consistent rows returned on a query that happens often. For example, one table holds user information, one holds news items. News items refrence the unique user ID, since a duplication of information would occur if it stored the plaintext username. When you list news items, you want to print the name of the user who posted it, which is held in a different table - make a view, and tada, no extra work for the coder. Creating a view and selecting off it is a real wrist-saver in cases like these.
And I really don't think that it takes that much longer to select off a view than doing a huge join - the SQL server has to do the same work (select with a big join) either way, it's just less typing when you use a view.
Maybe this elusive column-level security does the same sort of thing, I don't know. Care to explain what it is, so there's a better chance of it getting implemented?:)
I have to agree with the previous poster that Postgres is the best open-source RDBMS. I switched from MySQL to Postgres some time ago, MySQL just didn't have the feature set that Postgres does.
Postgres seems quite robust, but slower than MySQL. If you can live with the slight speed hit for the cool features (views, and stored procedures come to mind) it's well worth it.
How do you plan to overcome some of the window manager issues that have popped up? For example, Window Maker is `Gnome compliant', but (at least with a current Debian potato system) will not work under a Gnome-managed session because it does not support the Gnome --session-id command line option. Perhaps a Gnome-compliant WM certification could overcome this? It would seem like an advantage, as Gnome has a lot of momentum, and it would expose more new eyes to the diversity of window managers available for Linux, rather than pointing all those eyes at an ugly Enlightenment setup. Well, at least with RedHat 6.x and LinuxPPC, the E setup is ugly and horrible.:)
Are there any plans to support the recently-released Linux NetBEUI stack? Though it has little practical use, it could be a nice option for a small to mid-size network migrating from a Microsoft solution.
Just thought I'd drop a line and let everyone that Multihead support is working pretty well for me.
I've got a 16m Voodoo3 AGP connected to a PanaScope S700 17" Monitor at 1280x1024, and a 4m off-brand S3 ViRGE PCI connected to some crappy 14" at 640x480.
WindowMaker doesn't quite know what's going on (heh) - so even though I can move the pointer from one monitor to the other, I can't move a window once I've launched it on that display. It also looks like it has lost my dock/clip setup and all the apps I had docked there. In addition, I have one dock and clip on each display.
The Voodoo support seems good, as was the 3.3.6 driver.
The ViRGE driver sucks rocks. Even with no accelleration, I get snow and other graphical inconsistencies.
Also, even though xdpyinfo reports that I'm running at 16bpp, Netscape (4.7, standalone) has that can't-get-enough-colors look. XV/Gimp looks normal, though. Odd.
Odd, I don't see the Xinerama extension in xdpyinfo, and there doesn't seem to be a module for it in/usr/local/X11R6/lib/modules - anyone have a hint here?
Saw the same symptom on Debian frozen (potato) - makedepend hung on xterm, killing it let it continue to compile. Only other problem is that it couldn't find my kernel headers, so the tdfx DRI kernel module didn't compile. Sigh.
Just when I thought I might be able to live with the Debian frozen/stable branch, this comes up. I've no choice but to upgrade to the unstable branch once again when the XF86 4.0 debs are built.
So, when is that Debian stable-with-current-xfree86 thing gonna happen anyways?
Go take a look at the picture on the bottom of this page.
The page is showing the differences between the "TOOL" PS2 prototypes that were given to developers for testing and the production units.
It looks like there are 3 PCI slots on the TOOL unit. There are also some mysterious connectors (one to the right of the power cable, one on the bottom of the panel to the left of the cable) which look a bit like USB ports. Could be wrong on this one, as the PSX has similar connectors.
There's also what looks like an analog VGA output on the aforementioned panel.
I'm going to be very interested to see exactly what these really are.
Could someone with experience with the *BSD NAT implementation(s) post some info - or a link to info about it? I've had good success with the Linux 2.0/2.2 NAT/IPMASQ, and the loadable modules to support NAT-unfriendly protocols are good, but I wonder if there is a better way.
For example, you must manually specify additional FTP ports to masquerade if you want to access FTP servers on a port other then 21.
Also, with my DSL setup, I only get one IP, which goes to the Cisco 675 DSL Router. This means that no matter what, I have to use the crappy NAT on the Cisco, which breaks some things. The Linux IPMASQ modules also assume that the IP of the interface the masqueraded packets go out on is the IP they will come back to - not so with the aforementioned setup. So sometimes FTP breaks, and I can't do DCC sends on IRC, etc.
Of course, the real answer is a real external IP for at least one of my Linux boxes, but USWest (my DSL provider) does not give static IPs to home users, only to business customers. And business accounts are around $100/mo - way more than I want to be paying for a net connetion.
That may be the case, however I do not feel that it justifies the action. I could understand it if it was an original process that was created entirely by Amazon. But it's not. Customer referrals on the net have been happening since long before Amazon was a rustle in Bezos' pocketbook. Banner ads come to mind, and several years back when I worked at a 'net startup - before this patent was filed for - we were doing something very similar to this, but we called it partnering.
Bottom line, patenting other people's ideas is wrong. That does not mean that it doesn't happen every day - I'm sure it does - but I don't have to support companies that do with my money.
Of course, I could always try to get a patent on the win32 api's equivalent of fork(), sue Microsoft, and use the money to lobby for USPTO reform.
From the SRP page: "The Project's primary purpose is to improve network security from the ground up - by integrating secure password authentication into widely-used protocols instead of adding security as an afterthought."
Well, what's so wrong about that? Transmeta has been supporting the Linux userbase by providing employment for it's creator- and specifically encouraging his work on Linux- benefitting the Linux community as a whole. Now, granted that they are going to use Linux for their own ends, but I fail to see how this is any different than Red Hat employing Alan Cox or any of the other prominent community members.
In addidion, since they are positioning their product as a great platform to run Linux on, they will be expanding the market and number of people with eyeballs on Linux. This is also a good thing.
I think that they are doing enough for the community as a whole to use Linus as a marketing ploy. That does not mean that I agree with the tactic, but I don't think that there is anything inherently wrong with it.
Well, though this makes sense, why is there a lack of announcements about the support chipset(s)? If they are using something completely new, it would explain the 2-year dev cycle for the BIOS, but would not excplain the lack of announcement; however, if they are using some sort of existing (or something similar to an existing) support chipset, it should not have taken that length of time to produce a BIOS.
Of course, they do not specifically say that there was a 2-year long development, just a 2-year partnership. So take it all with a grain of salt. It does seem that there is a missing piece of the puzzle, though.
yes, but this is targeting the embedded market, not the pda market.
wince does run natively on the x86. many embedded devices (set-top boxes, winterms) use wince. i have seen several winterm-type systems running wince and the wince citrix ica client on a cyrix mediagx. the capio from boundless technolgy is a good example of this.
crusoe is x86 compatible. nothing is going to be written directly for the crusoe's vliw instruction set. it will all be written for x86, ppc, or whatever else the crusoe is emulating today.
well, wince runs on x86, therefore crusoe. kind of a moot point.
of course, it's not clear if crusoe can run apps for several different cpus at once. if not, then porting the ce compatibility layer might have some value. it may also have some usefulness if the source is released, as that would be a very attractive path for companies looking to move away from wince, or who do not want to pay m$ huge licensing fees for wince technology.
Slashdot Mirror
but regardless of who actually runs the fab units, there are serious problems making enough of it.
--
XFree86 4.0 has been released
glibc 2.1.3 has been released
apache 1.3.12 has been released
Linux 2.4.0 might get released
i love Debian, but they have the worst timing...
--
--
I'm sure that in a few years, when everyone has 300MHz SDRAM, Intel will regret the decision to stay with Rambus.
--
And I really don't think that it takes that much longer to select off a view than doing a huge join - the SQL server has to do the same work (select with a big join) either way, it's just less typing when you use a view.
Maybe this elusive column-level security does the same sort of thing, I don't know. Care to explain what it is, so there's a better chance of it getting implemented?
--
Postgres seems quite robust, but slower than MySQL. If you can live with the slight speed hit for the cool features (views, and stored procedures come to mind) it's well worth it.
Postgres works great with PHP, btw.
--
--
--
Just thought I'd drop a line and let everyone that Multihead support is working pretty well for me.
/usr/local/X11R6/lib/modules - anyone have a hint here?
I've got a 16m Voodoo3 AGP connected to a PanaScope S700 17" Monitor at 1280x1024, and a 4m off-brand S3 ViRGE PCI connected to some crappy 14" at 640x480.
WindowMaker doesn't quite know what's going on (heh) - so even though I can move the pointer from one monitor to the other, I can't move a window once I've launched it on that display. It also looks like it has lost my dock/clip setup and all the apps I had docked there. In addition, I have one dock and clip on each display.
The Voodoo support seems good, as was the 3.3.6 driver.
The ViRGE driver sucks rocks. Even with no accelleration, I get snow and other graphical inconsistencies.
Also, even though xdpyinfo reports that I'm running at 16bpp, Netscape (4.7, standalone) has that can't-get-enough-colors look. XV/Gimp looks normal, though. Odd.
Odd, I don't see the Xinerama extension in xdpyinfo, and there doesn't seem to be a module for it in
Saw the same symptom on Debian frozen (potato) - makedepend hung on xterm, killing it let it continue to compile. Only other problem is that it couldn't find my kernel headers, so the tdfx DRI kernel module didn't compile. Sigh.
It's supposed to work with S3, Matrox and 3Dfx cards. I already have a Voodoo 3000 as my primary, digging up a PCI S3 ViRGE now. :)
Just when I thought I might be able to live with the Debian frozen/stable branch, this comes up. I've no choice but to upgrade to the unstable branch once again when the XF86 4.0 debs are built.
So, when is that Debian stable-with-current-xfree86 thing gonna happen anyways?
Go take a look at the picture on the bottom of this page.
The page is showing the differences between the "TOOL" PS2 prototypes that were given to developers for testing and the production units.
It looks like there are 3 PCI slots on the TOOL unit. There are also some mysterious connectors (one to the right of the power cable, one on the bottom of the panel to the left of the cable) which look a bit like USB ports. Could be wrong on this one, as the PSX has similar connectors.
There's also what looks like an analog VGA output on the aforementioned panel.
I'm going to be very interested to see exactly what these really are.
Could someone with experience with the *BSD NAT implementation(s) post some info - or a link to info about it? I've had good success with the Linux 2.0/2.2 NAT/IPMASQ, and the loadable modules to support NAT-unfriendly protocols are good, but I wonder if there is a better way.
For example, you must manually specify additional FTP ports to masquerade if you want to access FTP servers on a port other then 21.
Also, with my DSL setup, I only get one IP, which goes to the Cisco 675 DSL Router. This means that no matter what, I have to use the crappy NAT on the Cisco, which breaks some things. The Linux IPMASQ modules also assume that the IP of the interface the masqueraded packets go out on is the IP they will come back to - not so with the aforementioned setup. So sometimes FTP breaks, and I can't do DCC sends on IRC, etc.
Of course, the real answer is a real external IP for at least one of my Linux boxes, but USWest (my DSL provider) does not give static IPs to home users, only to business customers. And business accounts are around $100/mo - way more than I want to be paying for a net connetion.
It would be extremely cool to see some built-in PGP for the email/news client. Or at least hooks to use an external PGP/GPG.
I think that a lot more people would be more interested in defending privacy/crypto rights if it was more visible to the end-user community.
Despite your words, the post was moderated down.
It's truly sad when an honest opinion - even if it is an opposing one - is adorned with the label of `troll'.
Freedom to Slashdot, and all netizens thereof.
Unfortunately, most of the bad press they get is right here...
That may be the case, however I do not feel that it justifies the action. I could understand it if it was an original process that was created entirely by Amazon. But it's not. Customer referrals on the net have been happening since long before Amazon was a rustle in Bezos' pocketbook. Banner ads come to mind, and several years back when I worked at a 'net startup - before this patent was filed for - we were doing something very similar to this, but we called it partnering.
Bottom line, patenting other people's ideas is wrong. That does not mean that it doesn't happen every day - I'm sure it does - but I don't have to support companies that do with my money.
Of course, I could always try to get a patent on the win32 api's equivalent of fork(), sue Microsoft, and use the money to lobby for USPTO reform.
From the SRP page:
"The Project's primary purpose is to improve network security from the ground up - by integrating secure password authentication into widely-used protocols instead of adding security as an afterthought."
Since NatSemi sold (parts of) Cyrix, their future has been pretty dim. Not to mention that their CPUs suck. See this link.
Well, what's so wrong about that? Transmeta has been supporting the Linux userbase by providing employment for it's creator- and specifically encouraging his work on Linux- benefitting the Linux community as a whole. Now, granted that they are going to use Linux for their own ends, but I fail to see how this is any different than Red Hat employing Alan Cox or any of the other prominent community members.
In addidion, since they are positioning their product as a great platform to run Linux on, they will be expanding the market and number of people with eyeballs on Linux. This is also a good thing.
I think that they are doing enough for the community as a whole to use Linus as a marketing ploy. That does not mean that I agree with the tactic, but I don't think that there is anything inherently wrong with it.
Well, though this makes sense, why is there a lack of announcements about the support chipset(s)? If they are using something completely new, it would explain the 2-year dev cycle for the BIOS, but would not excplain the lack of announcement; however, if they are using some sort of existing (or something similar to an existing) support chipset, it should not have taken that length of time to produce a BIOS.
Of course, they do not specifically say that there was a 2-year long development, just a 2-year partnership. So take it all with a grain of salt. It does seem that there is a missing piece of the puzzle, though.
yes, but this is targeting the embedded market, not the pda market.
wince does run natively on the x86. many embedded devices (set-top boxes, winterms) use wince. i have seen several winterm-type systems running wince and the wince citrix ica client on a cyrix mediagx. the capio from boundless technolgy is a good example of this.
crusoe is x86 compatible. nothing is going to be written directly for the crusoe's vliw instruction set. it will all be written for x86, ppc, or whatever else the crusoe is emulating today.
well, wince runs on x86, therefore crusoe. kind of a moot point.
of course, it's not clear if crusoe can run apps for several different cpus at once. if not, then porting the ce compatibility layer might have some value. it may also have some usefulness if the source is released, as that would be a very attractive path for companies looking to move away from wince, or who do not want to pay m$ huge licensing fees for wince technology.