one could try some luck to use gnustep, but while it does provide most of the core obj-c, it is lacking a lot in the display part -- hence it is unlikely to be such an easy 'port'.
keep in mind that macos is not an x11 gui...
albeit, it might have been not any more difficult than win port, though.
You should one day try and work in any given Finance department. Let me tell you from my personal experience: Business always wants to know a bunch of cra^H^H^H stuff that none of our twenty-year-old systems were ever designed to do. In fact the situation is so fluid that it does not even frequently make sense to try and implement a more permanent solution. So, what's the tool of choice? Excel. You can change a report in a few minutes and if our boss wants it with stripes on a side and an order of fries -- it is just a few mouse-clicks.
I can very much relate to the story -- sad but very true.
I think there are benefits of having it per-disc, and the claim is normally to ensure that swapping is done most efficiently -- dumping unneeded data onto a drive that is currently accessed.
This may be a bit imaginary, since reading it back may require a switch to another drive or controller all together.
Granted, I *am* a bit rusty (some claim 6 years) on the subject of Linux swap treatment -- but I distinctly remember that while you *could* have more than 128Mb total swap space (and I am referring to 2.x series, this is I am 100% positive), each partition had to be no more than 128Mb (although you could have multiple partitions in 128Mb chunks) -- anything above 128 would simply not be used by the system.
I've spent a few wonderful years in Linux-land between 1995 and c.a. 2000 -- but once you mature to *BSD, it becomes a bit difficult to go back... I still like Debian, however.
I suppose that for thread-safe implementation one could look at AOLServer. While it won't address PHP issues (one can use PHP with AOLSErver all the same, but the same trhread-safeness argument applies), a built-in Tcl interpreter is probably more than enough to replace the LAMP (with LAPT (Linux/AOLServer/Postgres/Tcl):)).
Have you ever actually looked *inside* an RTF file? Try it, and then pop open any TeX file and tell me if you see some similarities.
In *my* experience for *most* cases RTF, while possibly looking somewhat sub-par to original.doc, is fine. It may not be able to preserve some of the "advanced" formatting (especially when there is a crazy mixture of fonts/colors/pitches), and tables might not have facny borders around them, but the structure will be preserved.
As for parents mention of bullets going a-missing, I agree -- this sort of stuff happens (and in fact both ways -- sometimes OOo exported.doc would be missing them just as well). Probably there are more than one ways of defining them in a.doc, and not all of them are implemented in OOo (yet).
One area where OOo has still much to be desired is Calc (the spreadsheet). For a real Excel user Calc is simply not an alternative right now: it has half Excel's capacity (32768 rows vs. 65535), does not have good filters and does not support Excel's PivotTables. And, of course, it can't run macros (but this one is double-edged -- not being able to run macros saves it from the plague...).
... you need a separate swap partition for each drive you've got, not for the whole system. This maybe, however, a bit of BSDism -- that's the land I've been living in lately.
Also, has "128Mb swap limit" been surpassed in Lunix-land? Will you really be able to use whole 2Gb as a single partition or you'd have to split it up, ugh, 16 ways?
Lastly -- on my BSD boxes even with X and mozilla running swap usage would tend to be minimal, unless I am doing something really big on top of that (like running KDE with a bunch of apps together with a buildworld or a portupgrade -rRf x11/kde3)
MSFT is in a lot of problems specifically *because* of thir market domminance. While I would whole heartedly support the opening up of the code in general, the issue they are facing is very simple: if they let it free, chances are that:
(a) vulnerabilies would be discovered *and* exploited by malicious groups *before* the white/grey hats ever get to them
(b) it will be just as difficult to get the install base to patch the wholes -- look how many unpatched old machines are out there, every Joe-user and your-grandma out there...
Linux and *BSD advantage here (and in a way Mac) is small install base *on top* of the thorough peer audit that has been going for years now. And we still get to find some bugs here and there...
Put it another way: it sucks to be M$FT, either way you cut it...
I have a bit of a poblem believing a 40G number -- maybe the whole sourcesafe or whatver RC system is used can weigh in that number, but the system itself? sounds a bit too hgih... how heavy linux kernel + X + qt + kde would weigh (all unzipped)?
Slashdot Mirror
...was my first thought. gimme my metaverse, but spare me the horror of that wonder virus they had...
who knows... maybe even (® (/ (GNU Linux))
(/ (GNU) (Linux ®))
Fiat (company) owns Ferrari (trade mark/brand)
one could try some luck to use gnustep, but while it does provide most of the core obj-c, it is lacking a lot in the display part -- hence it is unlikely to be such an easy 'port'.
keep in mind that macos is not an x11 gui...
albeit, it might have been not any more difficult than win port, though.
Yeah, code is, probably, a lot more than 100K, but an executable itself is way under 100K, and that is *after* you unzip an archive:
/tmp/dnloads/kkrieger-beta.zip /tmp/dnloads/kkrieger-beta.zip
$ unzip -l
Archive:
Length Date Time Name
97280 04-11-04 23:45 pno0001.exe
5504 04-11-04 21:20 readme.txt
102784 2 files
Exposè?
OT: Are you serious? Check AquaDataStudio -- free and does by far more than the dateddino...
hmmm, isn't is because that same OLAP cube has been building for a few hours before?
Yes, and that is exactly why it becomes obsolete even before going live...
Not to advocate no-testing approach -- just to emphasise the point I was making.
Naturally, your financial software that is performing actual transactions is not as fluid, but your reporting apps -- they are the ones lagging...
I can very much relate to the story -- sad but very true.
It does, or at least it did with my Jag. Not the Pro, but still is a great product.
I think there are benefits of having it per-disc, and the claim is normally to ensure that swapping is done most efficiently -- dumping unneeded data onto a drive that is currently accessed.
This may be a bit imaginary, since reading it back may require a switch to another drive or controller all together.
Granted, I *am* a bit rusty (some claim 6 years) on the subject of Linux swap treatment -- but I distinctly remember that while you *could* have more than 128Mb total swap space (and I am referring to 2.x series, this is I am 100% positive), each partition had to be no more than 128Mb (although you could have multiple partitions in 128Mb chunks) -- anything above 128 would simply not be used by the system.
I've spent a few wonderful years in Linux-land between 1995 and c.a. 2000 -- but once you mature to *BSD, it becomes a bit difficult to go back... I still like Debian, however.
and foxes are dogs, btw.
You can use regexp's if you use Postgres.
There is a standard and non-compliance of various vendors -- well, this is just non-compliance.
I suppose that for thread-safe implementation one could look at AOLServer. While it won't address PHP issues (one can use PHP with AOLSErver all the same, but the same trhread-safeness argument applies), a built-in Tcl interpreter is probably more than enough to replace the LAMP (with LAPT (Linux/AOLServer/Postgres/Tcl) :)).
Have you ever actually looked *inside* an RTF file? Try it, and then pop open any TeX file and tell me if you see some similarities.
.doc, is fine. It may not be able to preserve some of the "advanced" formatting (especially when there is a crazy mixture of fonts/colors/pitches), and tables might not have facny borders around them, but the structure will be preserved.
.doc would be missing them just as well). Probably there are more than one ways of defining them in a .doc, and not all of them are implemented in OOo (yet).
In *my* experience for *most* cases RTF, while possibly looking somewhat sub-par to original
As for parents mention of bullets going a-missing, I agree -- this sort of stuff happens (and in fact both ways -- sometimes OOo exported
One area where OOo has still much to be desired is Calc (the spreadsheet). For a real Excel user Calc is simply not an alternative right now: it has half Excel's capacity (32768 rows vs. 65535), does not have good filters and does not support Excel's PivotTables. And, of course, it can't run macros (but this one is double-edged -- not being able to run macros saves it from the plague...).
... trouble is that it's not clear whether the beast is a bird, or a dog...
... you need a separate swap partition for each drive you've got, not for the whole system. This maybe, however, a bit of BSDism -- that's the land I've been living in lately.
Also, has "128Mb swap limit" been surpassed in Lunix-land? Will you really be able to use whole 2Gb as a single partition or you'd have to split it up, ugh, 16 ways?
Lastly -- on my BSD boxes even with X and mozilla running swap usage would tend to be minimal, unless I am doing something really big on top of that (like running KDE with a bunch of apps together with a buildworld or a portupgrade -rRf x11/kde3)
If you take a look at linked page, you'd see:
MSFT is in a lot of problems specifically *because* of thir market domminance. While I would whole heartedly support the opening up of the code in general, the issue they are facing is very simple: if they let it free, chances are that:
(a) vulnerabilies would be discovered *and* exploited by malicious groups *before* the white/grey hats ever get to them
(b) it will be just as difficult to get the install base to patch the wholes -- look how many unpatched old machines are out there, every Joe-user and your-grandma out there...
Linux and *BSD advantage here (and in a way Mac) is small install base *on top* of the thorough peer audit that has been going for years now. And we still get to find some bugs here and there...
Put it another way: it sucks to be M$FT, either way you cut it...
I have a bit of a poblem believing a 40G number -- maybe the whole sourcesafe or whatver RC system is used can weigh in that number, but the system itself? sounds a bit too hgih... how heavy linux kernel + X + qt + kde would weigh (all unzipped)?