StarOffice 6 was as straightfoward as configuring a data source. No harder than doing an external DB connect in Access. OpenOffice is the same thing.
That reminds me -- the database that comes with StarOffice (the name escapes me at the moment) blows goats on all platforms. Next to zero documentation, cryptic as all hell, and did I mention next to zero documentation? If you use StarOffice do yourself a favour and set up a nice Postgres database somewhere. Hell if you use Microsoft Office do the same. I can't believe how tedious it was to try to get the supplied DB running, even on win32.
Something I've been putting a lot of energy in to lately is XWT -- basically it's a remote widget system that takes all the plusses of X11 without the nasty lag. It uses XMLRPC or SOAP to talk to servers, which is where you'd get your OpenGL to work, I think. Spawn a simple XMLRPC server on the client to handle OpenGL functions on behalf of the app and you're set.
KDE people are trying to essentially produce a clone of what MS has done, and directly compete with them for Windows users. Smaller, programs more tied to each other, less independence for individual projects. GNOME people are trying to take an umbrella of projects and "condense" them into a desktop environment. Larger, more modular, programs more independent and simply packaged together.
Funny, I think that KDE has got the market on modularity. I can embed bits and pieces of practically any kpart-enabled KDE app into a bigger, grander app (think the Kroupware project, kvim integration to any text edit place, DCOP...)... My KDE desktop is nothing like my Win2k desktop -- I can do far more with it in terms of configuration and getting it to do exactly what I want than I could ever do with Win32, and that includes things like litestep and the other explorer addons/replacements.
Gnome has no corner on integration or modularity. In fact, I think it's hindered by GTK's insistence that C can do OO as well as C++.
I would imagine that this is the norm for most KDE users. Why bother reinventing the wheel?
I don't have GTK installed on my system, so that means I don't run a single Gnome app at all. KMail for mail, Korganizer for PIM and Klickety for my "waiting for the on-hold music to stop" diversion.
Why reinvent the wheel? That's precisely why I don't run Gnome or anything GTK. I am sick of "We hate C++ so we'll reimplement everything it does (poorly) in C." I got sick of two different desktop feels, fonts and stylings. (I hear RH has really cleaned this up now.) I got sick of running two desktops, so I run KDE. Qt rocks muh socks, Psi's a great instant messenger and anything with GTK I just don't run. It was an intentional decision on my part, and I'm sure I'm not the only one.
mplayer has actually an gui, and it is pretty themable/skinnable (I think much in the way gqmpeg or kjöfol is)
Like many people, I despise the GUI that they've come out with. Tiny buttons, can't read worth a shit, get in the way, really. I have set my wmv/avi/mpeg/divx/whatever mimetypes to invoke mplayer in a shell and use the default keyset to navigate. Sure beats YAPIGUI (Yet Another Poorly-Implemented GUI).
I don't mind paying service charges for VOIP, but I'm surprised I need to buy hardware.
The hardware is for implementing the codecs in DSP where you have sub-ms delays for the encode and decode. That is essential for decent qualty (i.e. not "I'm calling overseas and it's going around the globe 3 times" lag) audio.
I run Quicknet's Internet PhoneJACK PCI cards. Works great, but I don't get g.729a on the PCI version -- ISA only.:-(
Personally I like the Keramik window decorations, but I despise the widgets.
I use the KDE default widget set (HighColour Default I think it's called), Keramik for the window decorations, "Desert Red" for the colour scheme (I get so sick of blue or black-based schemes) and Noia for the icons. I'm not a big fan of transparency, but I have just a hint (96 or 98% opacity) for the menus -- what the hell, it's kind of neat and I have the processor power for it.
Screenshot is here. The IM app you see is Psi, the best damned Jabber IM I've run across. I'm not the author, but I have contributed a few patches to help the project.
Re:Is KDE trying to be Windows?
on
KDE 3.1 Released
·
· Score: 3, Informative
In some ways, KDE is up to Windows XP (video previews in the file manager), but in others it is not even at Windows 95 yet (easy folder sharing).
"Rightclick, select Share" isn't easy enough for you ?!!
> What this does is provides a KDE-based VNC viewing program What does it do that vncviewer doesn't do?
Scaled windows, better cut and paste support, no *XResource shit...
I used to use vnc with KDE... then I found out about krdc... I have never looked back.
Interestingly, the new kdrc in CVS HEAD also supports RDP right out of the box, and I hear rumblings of Citrix now and again too (using Citrix's libs, IIRC)
Just did another Oracle TAR (telephone assistance request) via their Metalink site.
Ya know, PostgreSQL has multiple levels of support as well... I believe you would have as good response times with them, especially at their Platinum level of support.
Well, that it is hard. Try forking a few thousand gzip processes and you'll see what I mean.
I compress almost anything these days with gzip -1. The difference between gzip -1 and gzip -9 on text or HTML or practically anything 7-bit ASCII is negligible, and it sure saves on the CPU and cache load.
The 14.1" TFT on my Compaq Evo N160 does not have a visible lagtime. It may be a millisecond or two,s ure, but it's no slower than any CRT I've used. That includes DVD watching and fast-faced gaming.
Do you really find the manual install easier? I can totally see someone preferring it to keep very up-to-date and control all level of installation, but EASIER?
Actually yes -- But it's more likely because I"m used to it -- with debian you have to pad through menus to get the kernel and so on and when you're done you still have to apt-get what you want... with slack you go though the menus once and you're done (to the large extent) -- Debian's tagsets are a good idea in theory but seem to be a mess in practise.
That's something I've never fully understood. Why are dependencies so farking hard to observe? I mean to a fresh newbie or someone who just doesn't have the time or interest in it, sure, but I've found apt to be more of a pain in the ass than anything else.
Disclaimer: I've been using Slackware since shortly after it first came out. I believe my first install of Linux was with the 0.99.x kernels, but it may have been the early 1.x.x kernels, I really can't remember.
Slackware's biggest bonus (and fault) has been that it lets you do as you please with packages. It'll let you install a package without having its dependencies installed. You run the app, and you get an error. Usually something along the lines of a library missing.
Now this isn't what I'd want a newbie to see or do, but for someone who's familliar with the system you run ldd on the binary and find out what's missing and install it. No big deal.
Especially now that CheckInstall is around, I have absolutely no issue with Slackware -- -current has logrotate which was sorely missing from the distro, but Checkinstall's the best. Create Slackware, Debian or RPM packages with a touch of the keyboard. Parallel installs, links, everything's supported.
Back to Slackware's packaging. What I disliked about Debian or RPM was that if the package didn't exist you had to go hunt around trying to find it and hope someone else made it, or else make it yourself, perhaps using Checkinstall. Unfortunately both RPM and DEB have heavier requirements -- dependency trees, documentation in the right spot, patches to make it fit within their particular file structure... you either use Checkinstall to make the package poorly (but validly), or you set out on a mission and end up being the maintainer of every package you make. Slackware doesn't care, which is great for me.
Sure Debian's got 10k packages, but it seems that everything I need isn't there, isn't complete, or is old, even in the unstable tree. FreeS/WAN with NAT-traversal and SA-disconnect, GNU-Radiusd, Psi, mplayer... that's just off the top of my head. If I don't install via packages (this goes for Perl modules from CPAN, too!) I now have TWO package managers to take care of -- the one in my head and the one in the distro. For me, Slackware compliments the one in my head (or vice-versa).
Anyway enough ranting -- I just don't understand how for anyone who's been using linux for any amount of time cares about dependencies. Even with upgrades.
Not quite, because DOS itself sometimes used the BIOS services, it just added a "system call" interface over them.
Yes, this was physically possible. The trick was that the BIOS often copied itself into RAM (i.e. it was shadowed) -- so the physical ROM wasn't necessary.
This was often done (and even current BIOSes do this, although why is often a question) because ROM access is quite slow compared to RAM access. It's a non-issue these days because just like Linux, there really isn't a whole hell of a lot Win2k/XP uses of the BIOS once it's booted.
Some problems are just not worth fixing and modded hardware is one of them.
That's not what the **AA and (I am betting) military institutuions are saying. For 99% of the people out there, I would agree with you 100%. but it's not the 99% of people who are pushing this tech. It's the very wealthy and very powerful 1% who want to have total control over your system and what you do with it.
As far as using the TPM for crypto acceleration, I too think that's a nifty idea. I mean ssl-engine already supports a myriad of accelerators, why not ones that are likely on your sytstem already (or at least in the next few years)?
They didn't need to. Linux doesn't need hardware help to be secure.
You are so wrong. Linux can do nothing if I've got a rogue PCI card or USB device installed. Linux can do nothing if I've got an ICE on the processor. Windows, OS/2, Mac, nobody can. It's beyond the scope of the OS' current capabilities, and it has no way of assuring itself within reasonable doubt that whatever it's talking to has not been tampered.
TCPA is all about that level of security. I can write TCPA-enhanced drivers which will validate that the PCI card I'm talking to hasn't been tampered from its original spec, almost right up to the output DACs or input ADCs. (I can still tap off any analog output or feed funky values to any analog input, but that's not a problem for most people designing this TCPA and Palladium stuff.)
Slashdot Mirror
StarOffice 6 was as straightfoward as configuring a data source. No harder than doing an external DB connect in Access. OpenOffice is the same thing.
That reminds me -- the database that comes with StarOffice (the name escapes me at the moment) blows goats on all platforms. Next to zero documentation, cryptic as all hell, and did I mention next to zero documentation? If you use StarOffice do yourself a favour and set up a nice Postgres database somewhere. Hell if you use Microsoft Office do the same. I can't believe how tedious it was to try to get the supplied DB running, even on win32.
Not to mention that pdf2ps or something and some perl could easily extract it.
Something I've been putting a lot of energy in to lately is XWT -- basically it's a remote widget system that takes all the plusses of X11 without the nasty lag. It uses XMLRPC or SOAP to talk to servers, which is where you'd get your OpenGL to work, I think. Spawn a simple XMLRPC server on the client to handle OpenGL functions on behalf of the app and you're set.
Nice, but not optimized. You should definitely use for(;;) or a goto instead of while(1),
uh... why? what's wrong with while(1)?
That is simply not true. A check is neutral.
Too many credit checks in too short a time do raise flags. At least in Canada. At least that is why my bank manager is saying.
I miss meept.
OOG the caveman was funnier, IMO.
KDE people are trying to essentially produce a clone of what MS has done, and directly compete with them for Windows users. Smaller, programs more tied to each other, less independence for individual projects. GNOME people are trying to take an umbrella of projects and "condense" them into a desktop environment. Larger, more modular, programs more independent and simply packaged together.
Funny, I think that KDE has got the market on modularity. I can embed bits and pieces of practically any kpart-enabled KDE app into a bigger, grander app (think the Kroupware project, kvim integration to any text edit place, DCOP...)... My KDE desktop is nothing like my Win2k desktop -- I can do far more with it in terms of configuration and getting it to do exactly what I want than I could ever do with Win32, and that includes things like litestep and the other explorer addons/replacements.
Gnome has no corner on integration or modularity. In fact, I think it's hindered by GTK's insistence that C can do OO as well as C++.
I would imagine that this is the norm for most KDE users. Why bother reinventing the wheel?
I don't have GTK installed on my system, so that means I don't run a single Gnome app at all. KMail for mail, Korganizer for PIM and Klickety for my "waiting for the on-hold music to stop" diversion.
Why reinvent the wheel? That's precisely why I don't run Gnome or anything GTK. I am sick of "We hate C++ so we'll reimplement everything it does (poorly) in C." I got sick of two different desktop feels, fonts and stylings. (I hear RH has really cleaned this up now.) I got sick of running two desktops, so I run KDE. Qt rocks muh socks, Psi's a great instant messenger and anything with GTK I just don't run. It was an intentional decision on my part, and I'm sure I'm not the only one.
mplayer has actually an gui, and it is pretty themable/skinnable (I think much in the way gqmpeg or kjöfol is)
Like many people, I despise the GUI that they've come out with. Tiny buttons, can't read worth a shit, get in the way, really. I have set my wmv/avi/mpeg/divx/whatever mimetypes to invoke mplayer in a shell and use the default keyset to navigate. Sure beats YAPIGUI (Yet Another Poorly-Implemented GUI).
"emerge freetype" and I get freetype with the 'in the grey' hack to make things look better, etc etc.
That's actually a pretty good pun...
the M-Player dev team certainly seem to have a somewhat flaky grasp of FREE software if they attempt to retrict distribution.
*cough*qmail*cough*
I don't mind paying service charges for VOIP, but I'm surprised I need to buy hardware.
The hardware is for implementing the codecs in DSP where you have sub-ms delays for the encode and decode. That is essential for decent qualty (i.e. not "I'm calling overseas and it's going around the globe 3 times" lag) audio.
I run Quicknet's Internet PhoneJACK PCI cards. Works great, but I don't get g.729a on the PCI version -- ISA only. :-(
Personally I like the Keramik window decorations, but I despise the widgets.
I use the KDE default widget set (HighColour Default I think it's called), Keramik for the window decorations, "Desert Red" for the colour scheme (I get so sick of blue or black-based schemes) and Noia for the icons. I'm not a big fan of transparency, but I have just a hint (96 or 98% opacity) for the menus -- what the hell, it's kind of neat and I have the processor power for it.
Screenshot is here. The IM app you see is Psi, the best damned Jabber IM I've run across. I'm not the author, but I have contributed a few patches to help the project.
In some ways, KDE is up to Windows XP (video previews in the file manager), but in others it is not even at Windows 95 yet (easy folder sharing).
"Rightclick, select Share" isn't easy enough for you ?!!
> What this does is provides a KDE-based VNC viewing program
What does it do that vncviewer doesn't do?
Scaled windows, better cut and paste support, no *XResource shit...
I used to use vnc with KDE... then I found out about krdc... I have never looked back.
Interestingly, the new kdrc in CVS HEAD also supports RDP right out of the box, and I hear rumblings of Citrix now and again too (using Citrix's libs, IIRC)
I don't know about the others but I can think of several better domains than those already suggested.
hairy.va/gina
tight.va/gina
wet.va/gina
...
Just did another Oracle TAR (telephone assistance request) via their Metalink site.
Ya know, PostgreSQL has multiple levels of support as well... I believe you would have as good response times with them, especially at their Platinum level of support.
Well, that it is hard. Try forking a few thousand gzip processes and you'll see what I mean.
I compress almost anything these days with gzip -1. The difference between gzip -1 and gzip -9 on text or HTML or practically anything 7-bit ASCII is negligible, and it sure saves on the CPU and cache load.
The 14.1" TFT on my Compaq Evo N160 does not have a visible lagtime. It may be a millisecond or two,s ure, but it's no slower than any CRT I've used. That includes DVD watching and fast-faced gaming.
Forgot a bit:
Do you really find the manual install easier? I can totally see someone preferring it to keep very up-to-date and control all level of installation, but EASIER?
Actually yes -- But it's more likely because I"m used to it -- with debian you have to pad through menus to get the kernel and so on and when you're done you still have to apt-get what you want... with slack you go though the menus once and you're done (to the large extent) -- Debian's tagsets are a good idea in theory but seem to be a mess in practise.
Because of cascading dependencies. One package may ultimately depend on updated versions of thirty or more other packages. That's where apt comes in.
You must be using Gnome then, I don't run into anything more than maybe a 3-level cascade...
Apt-get makes dependencies a thing of the past.
That's something I've never fully understood. Why are dependencies so farking hard to observe? I mean to a fresh newbie or someone who just doesn't have the time or interest in it, sure, but I've found apt to be more of a pain in the ass than anything else.
Disclaimer: I've been using Slackware since shortly after it first came out. I believe my first install of Linux was with the 0.99.x kernels, but it may have been the early 1.x.x kernels, I really can't remember.
Slackware's biggest bonus (and fault) has been that it lets you do as you please with packages. It'll let you install a package without having its dependencies installed. You run the app, and you get an error. Usually something along the lines of a library missing.
Now this isn't what I'd want a newbie to see or do, but for someone who's familliar with the system you run ldd on the binary and find out what's missing and install it. No big deal.
Especially now that CheckInstall is around, I have absolutely no issue with Slackware -- -current has logrotate which was sorely missing from the distro, but Checkinstall's the best. Create Slackware, Debian or RPM packages with a touch of the keyboard. Parallel installs, links, everything's supported.
Back to Slackware's packaging. What I disliked about Debian or RPM was that if the package didn't exist you had to go hunt around trying to find it and hope someone else made it, or else make it yourself, perhaps using Checkinstall. Unfortunately both RPM and DEB have heavier requirements -- dependency trees, documentation in the right spot, patches to make it fit within their particular file structure... you either use Checkinstall to make the package poorly (but validly), or you set out on a mission and end up being the maintainer of every package you make. Slackware doesn't care, which is great for me.
Sure Debian's got 10k packages, but it seems that everything I need isn't there, isn't complete, or is old, even in the unstable tree. FreeS/WAN with NAT-traversal and SA-disconnect, GNU-Radiusd, Psi, mplayer... that's just off the top of my head. If I don't install via packages (this goes for Perl modules from CPAN, too!) I now have TWO package managers to take care of -- the one in my head and the one in the distro. For me, Slackware compliments the one in my head (or vice-versa).
Anyway enough ranting -- I just don't understand how for anyone who's been using linux for any amount of time cares about dependencies. Even with upgrades.
Not quite, because DOS itself sometimes used the BIOS services, it just added a "system call" interface over them.
Yes, this was physically possible. The trick was that the BIOS often copied itself into RAM (i.e. it was shadowed) -- so the physical ROM wasn't necessary.
This was often done (and even current BIOSes do this, although why is often a question) because ROM access is quite slow compared to RAM access. It's a non-issue these days because just like Linux, there really isn't a whole hell of a lot Win2k/XP uses of the BIOS once it's booted.
Some problems are just not worth fixing and modded hardware is one of them.
That's not what the **AA and (I am betting) military institutuions are saying. For 99% of the people out there, I would agree with you 100%. but it's not the 99% of people who are pushing this tech. It's the very wealthy and very powerful 1% who want to have total control over your system and what you do with it.
As far as using the TPM for crypto acceleration, I too think that's a nifty idea. I mean ssl-engine already supports a myriad of accelerators, why not ones that are likely on your sytstem already (or at least in the next few years)?
They didn't need to. Linux doesn't need hardware help to be secure.
You are so wrong. Linux can do nothing if I've got a rogue PCI card or USB device installed. Linux can do nothing if I've got an ICE on the processor. Windows, OS/2, Mac, nobody can. It's beyond the scope of the OS' current capabilities, and it has no way of assuring itself within reasonable doubt that whatever it's talking to has not been tampered.
TCPA is all about that level of security. I can write TCPA-enhanced drivers which will validate that the PCI card I'm talking to hasn't been tampered from its original spec, almost right up to the output DACs or input ADCs. (I can still tap off any analog output or feed funky values to any analog input, but that's not a problem for most people designing this TCPA and Palladium stuff.)