I'm pretty sure that OO.o embeds fonts by default, with the intention of making the PDF perfectly rendered every time. It does this even with default fonts, IIRC.
You are supposed to be using Word. You prefer sliding the tab manually to setting up a style. If you were supposed to use OO.o, you'd prefer the style option.
I don't have much of a problem with OO.o, except that it vomited all over 200 pages I was working on, leaving everything corrupted. I used a PDF export I was looking over to extract the text, then put in into Texmaker. Happy as a camper now. What's going to screw up plain text?
If you share documents with a Korean, you'd better get the Hangul Office viewer. What? Never heard of Hangul Office? It's got the monopoly over here, with MS Office being the "also ran." It's always been that way, too. I'm sure people in other countries can point out where MS Office is behind, as well.
The GP uses Ubuntu. Ubuntu doesn't get RPM hell, because it uses.debs. On Debian Unstable or an Ubuntu Tribe release, you can run into.deb hell, but the.deb system with apt (aptitude / synaptic) on top of it is virtually bulletproof. Nothing every breaks on a stable release. The repos are so large that it's rarely necessary to add outside.debs, reducing the chance something will break.
I've been using Linux since 1997, so I understand your problems. I used RH or RH-based distros for years. I broke stuff all the time. The moment I moved to Debian-based distros about three years ago, all those problems went away. (I understand that Yum has fixed a lot of the issues in RH, but my K12OS buddies still seem to get hosed every once in a while.)
GNUCash is not the only money app in town. I never understood it, either. Grisbi and KMyMoney are easier to use apps for Gnome and KDE, respectively. I feel your pain about online banking, though. In Korea, the banks have all standardized on an ActiveX plugin for IE. Meh.
My laptops came with the rt2500. It used to be really common and I think it's now become to Wifi what the rt8139 is to 10/100 NICs -- completely ubiquitous. The new workstation I bought the missus came with a shit Wifi that I returned for an RT61, also well supported. These chips don't work well with Network Manager using older versions of the drivers, but newer drivers are fine. Ubuntu 7.10 will work with them right out of the box (WEP/WPA).
So, you take an old game that still has some interest, ad adds, then release it for free?
Add ads. Add ads. Look at it again. Add ads. Remember it. Wow.
So if I write some code and want it and future versions to be available under the BSD license I should GPL it? That does not make sense.
As far as I can tell, there is no way to ensure that future versions of a license will be BSD, since the BSD allows virtually any use. If you want to mandate that the source remains open, you need a copyleft. If you want to give freedome to do anything, use BSD/MIT-style licenses. It's really pretty cut and dried.
Before you set yourself upon me, please read my entire post. From the last two line:
Why's everyone got their panties in a bunch over something which the license allows? (I also understand the origin of this anger being the removal of the attribution and BSD text from the wireless kernel patch proposed, but it was just proposed, not accepted, and the situation was immediately resolved.)
When I read the original OpenBSD thread, the author of the driver (originally dual-licensed BSD/GPL) was the one who submitted the GPLed driver to the Linux kernel, so he's not denying himself anything. Additionally, the original BSDed code is still available for anyone to take. No one squirreled that code away. The fork of the BSD/GPL code to a GPL project didn't lock anyone out.
Sure, improvements on the GPL side won't be BSD licensed, but any proprietary company which takes it won't contribute back, either. This is what the BSD license fans call "freedom." "Freedom" here means the ability to do anything you want with the code, including close it up entirely. GPL fans use "Free" tomean that the code stays open. Don't confuse the two.
Telling me I can do something and then rebuking me for doing it is kind of a shitty practice, isn't it? If you want me to share code with you, put it in the license. Microsoft and Real won't contribute back, either.
That's kind of what I was trying to get at. The freedom that the BSD folks talk about is the freedom to do virtually anything you want with the code. I find it ironic that there are complaints about code not being shared back in this case.
It's not much different from back when Transgaming first started with Cedega. There were protests from the Wine guys that the code had been taken and nothing was returned. The rational members in the debate were saying "Then why license the code the way you did?" Wine switched to LGPL shortly after that, if I remember correctly. Maybe OpenBSD should do the same if they want to guarantee code sharing.
I've read Theo's rant, and I found the section about not sharing code back to be pretty humorous, considering that's the way the BSD license is written. If you wanted to ensure that code be shared back into your projects, you'd use a copyleft-style license instead of a BSD/MIT-style license, wouldn't you?
I personally prefer the GPL, but I've been around Slashdot for a few years and understand the "more freedom" argument from BSD fans. That "more freedom" is the freedom to relicense or even completely close up the code, returning nothing to the original project.
Why's everyone got their panties in a bunch over something which the license allows? (I also understand the origin of this anger being the removal of the attribution and BSD text from the wireless kernel patch proposed, but it was just proposed, not accepted, and the situation was immediately resolved.)
I said that Linux has had a stable API for some time. That a stable API can produce a stable ABI does not mean that Linux has or will have a stable ABI. In fact, Linus has vocally opposed setting an ABI, so I doubt there ever will be one. They are unrelated.
I''ve only been using Linux full-time for ten years, so I might very well be considered a newbie, but even I could write scripts for all the major distros (using yum, apt, or yast), which installed all the build depends, compiled the module from a common source file, and inserted it. This wouldn't cover all the bizarre one-off distros, but users of those distros have no problem compiling their own modules from the same single tarball on the CD. This isn't what you want. You want an ABI. I see no difference to the user.
This situation is solved by #2, above. The support pains are no greater than a binary driver, and will actually likely cause fewer problems for the system because the driver was compiled instead of wedged in.
So the manufacturer makes a nice little statically compiled program which prompts the user "next" "next" all the while using the scripts in the background, transparent to the user. Are you happy yet? Or is it not enough like Windows for your taste.
Almost ALL the Ubuntu froum support requests have been about drivers related to Nvidia and ATI proprietary drivers not working properly or not being able to be loaded. Do you really want to increase the number of drivers with this model? Virtually every Intel driver, though, is open sourced, well-written, and in the kernel. An all-Intel machine just works out of the box with no hassles. (There's a caveat about a bug related to the BIOS coded resolutions in some Intel video chipsets)
Thanks for the unnecessary advice. Did I say I was treating her like a Windows user? No. I said that the fact that she asked me how to install particular programs instead of how to do something opened my eyes a little. So I explained to her a little. Wait... maybe it was a lot. I wanted to help her understand her new system and how it worked. In fact, I wrote quite a fewtutorialsforher, so take a breath before you flame. Asshole.
By "didn't make it into the kernel," I'm assuming that you meant that the driver hadn't been accepted by the time that version of Suse was published. I would rather have a staple API (which Linux has had through most of the 2.6 kernel and which it is likely to have for some time) than ABI. The manufacturers which show any interest in publishing drivers already can and really have no problem doing it.
I don't think a driver needs to be binary to be on a disk with the hardware. Why couldn't the manufacturer supply a well-written script which simply compiles the driver for the machine in question? If they provide the source code, it'll almost certainly be in the main kernel shortly, but older kernels can still use the driver on the disk.
Driver development for most kinds of hardware is scrimped on almost everywhere. It's the kind of thing that happens under tight schedules with small budgets and is hurried out the door. That's the reason very few companies will develop drivers for Linux, unless Linux already makes up a fair share of the market, as in server hardware.
When a friend took over my laptop with Ubuntu on it, the first thing she said was that she needed to download her preferred Windows movie player (Somthing like "Gom," I think). The next ten minutes were filled with questions like "Well then, how to I get XXX program to work on it?" There were no "How do I accomplish XXX." Really opened my eyes.
Beautiful That's about right. After answering the same question for the 100th time, I have less patience. I guess I'm not cut out to be a help desk worker.
I have noticed, though, that both the Ubuntu Forums and the K12OS mailing lists are chocked full of people who seemingly never tire of the same questions. Ubuntu even gives guidance to forum participants that "RTFM" is not an acceptable answer.
I don't want to see KDE, Gnome, and XFCE merged into a single desktop. Having all this diversity is great.
What I would like to see is either a framework similar to wxwindows which allows a developer to write an application that can be run natively in any of those three (or even more) DEs, or a project which allows compilation of one DE's program in another DE, similar to what the Wine developer tools seek to do with Windows apps, allowing them to be easily ported to Unix.
Then I wouldn't need silly themes and widgets which mask the surface differences between DE's applications but which leave glaring usability problems because of differences in architecture. I think there would be more of a level playing field, and Krita could defeat Gimp (reverse if you like) without causing any disruption to someone's DE of choice.
WAAAAY pie in the sky, but the question wasn't about creating a realistic scenario.
Slashdot Mirror
I'm pretty sure that OO.o embeds fonts by default, with the intention of making the PDF perfectly rendered every time. It does this even with default fonts, IIRC.
You are supposed to be using Word. You prefer sliding the tab manually to setting up a style. If you were supposed to use OO.o, you'd prefer the style option.
I don't have much of a problem with OO.o, except that it vomited all over 200 pages I was working on, leaving everything corrupted. I used a PDF export I was looking over to extract the text, then put in into Texmaker. Happy as a camper now. What's going to screw up plain text?
If you share documents with a Korean, you'd better get the Hangul Office viewer. What? Never heard of Hangul Office? It's got the monopoly over here, with MS Office being the "also ran." It's always been that way, too. I'm sure people in other countries can point out where MS Office is behind, as well.
I bought it in Korea. It's a TG, but it's really a rebranded Averatec.
Well, Dell was said to be pressuring AMD/ATI for better video drivers. Business indeed!
The GP uses Ubuntu. Ubuntu doesn't get RPM hell, because it uses .debs. On Debian Unstable or an Ubuntu Tribe release, you can run into .deb hell, but the .deb system with apt (aptitude / synaptic) on top of it is virtually bulletproof. Nothing every breaks on a stable release. The repos are so large that it's rarely necessary to add outside .debs, reducing the chance something will break.
I've been using Linux since 1997, so I understand your problems. I used RH or RH-based distros for years. I broke stuff all the time. The moment I moved to Debian-based distros about three years ago, all those problems went away. (I understand that Yum has fixed a lot of the issues in RH, but my K12OS buddies still seem to get hosed every once in a while.)
GNUCash is not the only money app in town. I never understood it, either. Grisbi and KMyMoney are easier to use apps for Gnome and KDE, respectively. I feel your pain about online banking, though. In Korea, the banks have all standardized on an ActiveX plugin for IE. Meh.
My laptops came with the rt2500. It used to be really common and I think it's now become to Wifi what the rt8139 is to 10/100 NICs -- completely ubiquitous. The new workstation I bought the missus came with a shit Wifi that I returned for an RT61, also well supported. These chips don't work well with Network Manager using older versions of the drivers, but newer drivers are fine. Ubuntu 7.10 will work with them right out of the box (WEP/WPA).
So, you take an old game that still has some interest, ad adds, then release it for free?
Add ads. Add ads. Look at it again. Add ads. Remember it. Wow.
Install Ubuntu to a hard drive, customize, then: /home
mount -t tmpfs tmpfs
So if I write some code and want it and future versions to be available under the BSD license I should GPL it? That does not make sense.
As far as I can tell, there is no way to ensure that future versions of a license will be BSD, since the BSD allows virtually any use. If you want to mandate that the source remains open, you need a copyleft. If you want to give freedome to do anything, use BSD/MIT-style licenses. It's really pretty cut and dried.
The author himself disagrees with Theo (and apparently you, as well). Check it out
Before you set yourself upon me, please read my entire post. From the last two line: Why's everyone got their panties in a bunch over something which the license allows? (I also understand the origin of this anger being the removal of the attribution and BSD text from the wireless kernel patch proposed, but it was just proposed, not accepted, and the situation was immediately resolved.)
When I read the original OpenBSD thread, the author of the driver (originally dual-licensed BSD/GPL) was the one who submitted the GPLed driver to the Linux kernel, so he's not denying himself anything. Additionally, the original BSDed code is still available for anyone to take. No one squirreled that code away. The fork of the BSD/GPL code to a GPL project didn't lock anyone out.
Sure, improvements on the GPL side won't be BSD licensed, but any proprietary company which takes it won't contribute back, either. This is what the BSD license fans call "freedom." "Freedom" here means the ability to do anything you want with the code, including close it up entirely. GPL fans use "Free" tomean that the code stays open. Don't confuse the two.
Telling me I can do something and then rebuking me for doing it is kind of a shitty practice, isn't it? If you want me to share code with you, put it in the license. Microsoft and Real won't contribute back, either.
That's kind of what I was trying to get at. The freedom that the BSD folks talk about is the freedom to do virtually anything you want with the code. I find it ironic that there are complaints about code not being shared back in this case.
It's not much different from back when Transgaming first started with Cedega. There were protests from the Wine guys that the code had been taken and nothing was returned. The rational members in the debate were saying "Then why license the code the way you did?" Wine switched to LGPL shortly after that, if I remember correctly. Maybe OpenBSD should do the same if they want to guarantee code sharing.
I've read Theo's rant, and I found the section about not sharing code back to be pretty humorous, considering that's the way the BSD license is written. If you wanted to ensure that code be shared back into your projects, you'd use a copyleft-style license instead of a BSD/MIT-style license, wouldn't you?
I personally prefer the GPL, but I've been around Slashdot for a few years and understand the "more freedom" argument from BSD fans. That "more freedom" is the freedom to relicense or even completely close up the code, returning nothing to the original project.
Why's everyone got their panties in a bunch over something which the license allows? (I also understand the origin of this anger being the removal of the attribution and BSD text from the wireless kernel patch proposed, but it was just proposed, not accepted, and the situation was immediately resolved.)
- I said that Linux has had a stable API for some time. That a stable API can produce a stable ABI does not mean that Linux has or will have a stable ABI. In fact, Linus has vocally opposed setting an ABI, so I doubt there ever will be one. They are unrelated.
- I''ve only been using Linux full-time for ten years, so I might very well be considered a newbie, but even I could write scripts for all the major distros (using yum, apt, or yast), which installed all the build depends, compiled the module from a common source file, and inserted it. This wouldn't cover all the bizarre one-off distros, but users of those distros have no problem compiling their own modules from the same single tarball on the CD. This isn't what you want. You want an ABI. I see no difference to the user.
- This situation is solved by #2, above. The support pains are no greater than a binary driver, and will actually likely cause fewer problems for the system because the driver was compiled instead of wedged in.
- So the manufacturer makes a nice little statically compiled program which prompts the user "next" "next" all the while using the scripts in the background, transparent to the user. Are you happy yet? Or is it not enough like Windows for your taste.
Almost ALL the Ubuntu froum support requests have been about drivers related to Nvidia and ATI proprietary drivers not working properly or not being able to be loaded. Do you really want to increase the number of drivers with this model? Virtually every Intel driver, though, is open sourced, well-written, and in the kernel. An all-Intel machine just works out of the box with no hassles. (There's a caveat about a bug related to the BIOS coded resolutions in some Intel video chipsets)Shouldn't any computer powerfull enough to run Vista be "powerful enough to not need such a draconian throttling?"
Thanks for the unnecessary advice. Did I say I was treating her like a Windows user? No. I said that the fact that she asked me how to install particular programs instead of how to do something opened my eyes a little. So I explained to her a little. Wait ... maybe it was a lot. I wanted to help her understand her new system and how it worked. In fact, I wrote quite a few tutorials for her, so take a breath before you flame. Asshole.
By "didn't make it into the kernel," I'm assuming that you meant that the driver hadn't been accepted by the time that version of Suse was published. I would rather have a staple API (which Linux has had through most of the 2.6 kernel and which it is likely to have for some time) than ABI. The manufacturers which show any interest in publishing drivers already can and really have no problem doing it.
I don't think a driver needs to be binary to be on a disk with the hardware. Why couldn't the manufacturer supply a well-written script which simply compiles the driver for the machine in question? If they provide the source code, it'll almost certainly be in the main kernel shortly, but older kernels can still use the driver on the disk.
Driver development for most kinds of hardware is scrimped on almost everywhere. It's the kind of thing that happens under tight schedules with small budgets and is hurried out the door. That's the reason very few companies will develop drivers for Linux, unless Linux already makes up a fair share of the market, as in server hardware.
When a friend took over my laptop with Ubuntu on it, the first thing she said was that she needed to download her preferred Windows movie player (Somthing like "Gom," I think). The next ten minutes were filled with questions like "Well then, how to I get XXX program to work on it?" There were no "How do I accomplish XXX." Really opened my eyes.
Is that website in the sig yours? I laughed for 10 minutes going through it. Brilliant. Sick, but brilliant.
Beautiful That's about right. After answering the same question for the 100th time, I have less patience. I guess I'm not cut out to be a help desk worker.
I have noticed, though, that both the Ubuntu Forums and the K12OS mailing lists are chocked full of people who seemingly never tire of the same questions. Ubuntu even gives guidance to forum participants that "RTFM" is not an acceptable answer.
You're not the only one who thinks so.
I don't want to see KDE, Gnome, and XFCE merged into a single desktop. Having all this diversity is great.
What I would like to see is either a framework similar to wxwindows which allows a developer to write an application that can be run natively in any of those three (or even more) DEs, or a project which allows compilation of one DE's program in another DE, similar to what the Wine developer tools seek to do with Windows apps, allowing them to be easily ported to Unix.
Then I wouldn't need silly themes and widgets which mask the surface differences between DE's applications but which leave glaring usability problems because of differences in architecture. I think there would be more of a level playing field, and Krita could defeat Gimp (reverse if you like) without causing any disruption to someone's DE of choice.
WAAAAY pie in the sky, but the question wasn't about creating a realistic scenario.