Zones are indeed amazing but we don't have a use-case for them on our production hosts. Maybe we could have used "zone-images" to deploy our stuff but that'd really only be an excuse to use zones for a task that seems to be better suited to apt (dependency tracking, controlled distribution of updates etc.).
ZFS, no doubt, is something we miss.
SMF. Well, as often with solaris I love the concept but hate the implementation. Yes, it beats sysv-init hands down. But, gah, XML, and many of the pkgs on solaris freeware don't even support it yet. We learned how to roll our own pkgs (with SMF etc.) but the lack of a package-manager akin to apt turned this into a time sink.
DTrace is a similar story. Ofcourse it is powerful but on a every day base we simply don't need that power. We prefer the simplicity of strace which has, so far, been good enough when we needed it and never forced us to wade through documentation for supposedly "simple" tasks like dtrace did. Dtrace alone seems to be basically useless until you wrap it up in a fairly elaborate script for the task at hand. Yes, "DTraceToolkit" provides these scripts for many common tasks, but not for all. Looking back at the first dtrace tutorial that I found (http://developers.sun.com/solaris/articles/dtrace_example.html?feed=DSC) I can still only shake my head about the effort it takes for such a simple task.
About messing on the command line often: No, we don't need that "often" but regularly. We install stuff, upgrade stuff, like everyone does. The major gripe was: We don't want to repeat ourselves for n hosts. Ideally we want to roll packages and distribute them in a controlled manner. Solaris left us out in the cold here and implementing a 3rd party framework like puppet feels wrong when linux never even made you think about that.
No, pkgadd -d is not too hard for us. But manually downloading each dependency from solarisfreeware or whatever source and installing it on each individual host is. Not too hard as in "we can't do it" but too hard as in "dude, that feels backwards". Feel free to enlighten me. How do *you* upgrade curl (random example) on 8 solaris hosts? In debian we review the distro pkg and roll our own when necessary, test it, push it to the mirror and the nightly update pulls it to all hosts. What tools did we miss that enable an equivalent workflow for solaris?
Generally I wouldn't say we weren't able to handle solaris. I'd say it turned out we didn't *want* to. It's very well possible that AIX would break us into a quivering goop. For that precise reason I have no intention to ever touch it? It has nothing to offer that interests us, so why should I even consider it?
Well and finally, your last statement makes you sound strikingly similar to the Sun sales reps that we had. They also kept trumping the horn of "use our modern OS with features not yet available for linux" to "utilize our kickass hardware to the fullest".
The problem probably lies in the definition of "utilizing our hardware to the fullest". For you and Sun that probably means to squeeze out the last 10% of performance. For us it means being able to fluidly run and maintain the hosts (that includes a sane update-procedure etc.) with a minimum cost in terms of manhours.
In other words: The time we saved on "solaris administration overhead" since we abandoned it quite likely paid our last 3 xfires alone.
You may blame it on our lack of solaris expirience or even on your perceived "ineptitude". Still it was the right decision for us.
There are lots and lots of people here who really and truly believe that Linux is just an upgrade path to Solaris. In other words... Once people start running Linux on Sun hardware, they'll "want more", and "step into the big league" with Solaris. It's kind of sad, when it's not irritating.
Funny. It has been exactly the opposite for us. We're running a bunch of xfires (14 boxes total, 4100, 4200, 4150) here and initially started out with solaris because the wise guys said it's faster, more stable, oh and no least you get that shiny "platinum support" badge...
Yea it was all that and the zfs hype, what could possibly go wrong?
Nothing much to be honest. We fell in love with the hardware immediately and the machines hummed along without too much trouble. Postgres performs well, java performs well, and ZFS snapshots are a blessing.
Despite all that superficial happyness we switched most of the hosts to linux (and aim for 100% linux) after a few months. We still love ZFS (and can't wait for a linux equivalent) but that alone couldn't justify sticking to solaris for us.
What broke it for us is the userland with all its subtle differences to linux, or in other words: the learning curve. This may sound strange when talking about a UNIX OS but as a linux shop we're spoiled by the GNU toolchain, by dead-simple package management and all the little everyday things that just work a tiny little bit different under solaris.
I'm not saying the linux-UI is better (actually, it is in many places, but that's not the point here), it's just that we all grew up with linux, so the solaris CLI "felt like a really old version of linux" (to paraphrase a coworker) from the start.
We didn't slack, mind you. We tried hard to make that feeling stop. We read the books and collected bigadmin bookmarks like trophies. We changed the default-shell to bash and installed the GNU tools to keep our sanity but otherwise did our best to treat solaris with respect and resisted the urge to dress it up to look more like linux.
It didn't work out.
I could rant for days about the many little things that drove us away but I'll try to focus on a few of the most significant points here:
1. Package Management (the lack thereof) Pkg-add is bad joke when you're used to apt-get and emerge. JumpStart feels like an insult when you're spoiled by FAI. I can only guess how Sun expects us to keep our multiple solaris boxes in sync. Maybe they sell that as one of their many enterprise service?
2. Google doesn't work well for solaris Not really something we can blame on solaris or Sun but time after time we were astonished as to how hard it is to find useful help for specific solaris problems via google. Howto's and Tutorials about all things solaris are generally very sparse. Due to this "learning by doing" doesn't work as well for solaris as it does for linux.
3. The sun website SUCKS Sure there is a lot of documentation, if you can find it in the pile of rubble that sun calls a website. But even the stuff we found was not always helpful. Sun documentation tends to be very verbose while still often glossing over important details. Sun docs often feel like they expect you to print them out and put them under your pillow. We don't work that way. We're spoiled by straighforward howtos, examples, stuff that gets us going fast. We're the impatient youngsters.
Well, this got longer than I intended. I'll close with saying that we'll keep buying sun hardware. The xfire series is the best piece of kit (at a very competitive price) that I have ever seen and it runs linux like a champ.
But linux as an "upgrade path to solaris"? Ha. Good joke. In my world solaris has it's place on big iron and in areas where the last bit of performance really matters. For everyone else the natural choice is what they're familar with. And who grows up with solaris these days?
Yep, they have amazing hardware at *excellent* prices, too. I don't give a damn for solaris or any sun software but their xfire series is the best bang for buck you can buy these days.
I don't think GP's analogy was all off. At least not more than your all-you-can-eat analogy is off...
Maybe we should just try to do without analogies at all?
Here's my take:
R&D happens all the time, technology is evolving. Networking equipment becomes faster and cheaper every day, this applies not only to your ethernet PCI-card but also to the big honking router equipment that ISPs use.
It is not more expensive to provide you with an 10MBit/s uplink today than it was to provide you with a 2MBit/s uplink a few years back. The equipment for that costs roughly the same, it simply utilizes the existing physical infrastructure better.
Ofcourse there are physical limits to what you can push through the last mile or through a deepsea cable.
If ISPs were seriously worried that all those VDSL last-mile customers may eventually saturate the backbone then, doh, how about stop selling VDSL for a while? Or throttling it? At least until it becomes financially feasible to upgrade those backbone lines?
The whole "Gah, the internets will explode"-fud is just nonsense.
*If* the backbones become saturated then a very simple thing will happen: Last-mile bandwidth prices will increase. The rich will get the fast links, the poor will be stuck with whatever is considered "slow" at that point in time.
$20 mio is pocket change for intel. If that's really all they put into research of parallel computing then that doesn't seem to rank so high on their priority list.
Wouldn't surprise me as the market for parallel computing is fairly small (HPC) when compared to the cash cow sectors (server, consumer).
I think the article is hyperbole. There isn't much need in those latter markets for parallelism at the hardware level because only few tasks can be parallelized at that level.
Hope they can do it faster than the whole Mozilla rewrite ended up taking.
Hell yea!
I squirm whenever I read about all the manyears they constantly throw at refactoring the blackhole that is the mozilla codebase.
Really, how long can it take to write a new browser from scratch? I'm not saying that it's not a serious undertaking but I would really love to see what all those skilled mozilla devs could achieve if all the legacy crap was suddenly taken off their shoulders...
Better yet, I'm sure that not all parts are broken beyond salvation. Why not cherrypick the good stuff (and *only* the good stuff) and build your new world around it!
Large parts of gecko could likely survive the transition. Same for the JS engine of choice. Everything UI would have to go (remember: XUL was originally meant as a practical joke) but that part is not so hard to reinvent better.
I'm playing a bit at being devil's advocate, but why isn't there another option?
Well, you're painting it very black & white while in reality it is many shades of gray.
Yes, XP drivers are "pretty good" but so are linux drivers these days. Also you don't need the CLI for everyday tasks in a modern distro anymore. The GUI frontends are improving and if you're literally spending your time in firefox, openoffice etc. then there's just no need to drop to CLI - just as there is no need in XP.
Further, if you really consider tracking down registry entries any better or easier than working with a CLI then I guess many people would beg to disagree;-)
Well, I only came in to clear up your misconception about DOS being anything like a unix shell. Not to draw you over to linux or anything.
The whole hardware-support story is an old hat. It basically boils down to: If you want to use linux then buy hardware that's supported by linux. Which, for the majority of peripherals, is not hard anymore. Google for "$name_of_my_gadget linux" in advance and in 90% of cases you'll learn that it runs without problems.
Furthermore it's also an old hat that the driver-situation in windows is not flawless either. Yes, you get a pretty GUI, but if the pretty installer fails then you're SOL. Even if you wanted to tinker - there is no ndiswrapper to try, no kernel options to tweak and usually no alternative source for drivers either. If your old $whatever is not supported in vista - tough luck. Not even an uber-user can help you there.
So, finally, to each it's own. You prefer the GUI, so stick with what you like. But don't label yourself as the prototype of an "end-user". I know quite a few "end-users", especially of the technically clueless type, who have quite happily switched to linux recently. If really all you want to do is browse the web and do a bit of office work (without touching a command line) then an ubuntu box can serve you well and in fact *save* you quite a bit of trouble with regard to "tweaking the personal firewall", re-installing after trojan infections, re-installing after a windows update screwed up your drivers or re-installing after your office began to behave wierd for no obvious reason.
You're not re-learning DOS when you switch to linux. Instead you're learning a true unix shell. Which gives you access to a large library of insanely powerful, time-tested commands that can be combined in an uncountable number of ways.
Those not only enable you to solve a large number of problems (actually whole categories of problems) quicker and more reliable than any GUI could but they further enable you to automate your solutions for re-use.
What may seem "inconvenient" at first is your first glimpse at the power of UNIX.
Don't discard it so quickly because it's only white text on a black screen and "looks like DOS". It's not DOS.
He doesn't need to. The login credentials were in the subject line. He could just scrap them off the web interface without clicking on a mail or (more likely) use the POP3/IMAP LIST command to fetch the list, again without actually reading a mail.
Furthermore I know for sure that imap (and i guess pop3, too) has a command to mark a mail as unread again.
Benefit of the doubt? For what "debugging purpose" should this program send a copy of all passwords anywhere?
Think about what it actually does: It logs into gmail and copies all your mail to somewhere else. There is no reason for any developer or user to ever care to see the password!
And even if there *was* a valid reason to do so: Why send it out by e-mail (many lines of code) instead of just displaying it in a popup-dialog (one line of code)?
Long story short: There is no benefit of the doubt here. This "feature" was put in deliberately for the single, malicious purpose of collecting other people's gmail passwords. And, to top it off, he even *sold* the software for real money. Someone should sue this guy into oblivion...
Yes, solaris is a bitch. Has been that way forever and will probably stay that way for a while. But the argument was about performance and that is the precise and primary reason why so many people still bother with the "ugly bully".
BSD and linux fanboys arguing about "performance crowns" sounds like kart-racers arguing about "who has the fastest car in the world" to me.
It's cute to watch but sometimes I just can't resist...
Ehm, *which* crown? Last time I checked most performance crowns were worn by solaris.
Re:Might Be A Challenge
on
Is AMD Dead Yet?
·
· Score: 2, Insightful
Well, I cannot say that I'm deeply involved with the numbers game but these figures from AppleInsider seem to suggest that Apple's share, while significant, is not even in the same ballpark as Dell or HP.
Even if only 25% of the Dell's are shipped with AMD CPUs that would still be more than all of Apple. As said, I have no idea about the actual figures (maybe Dell sells only 1% AMD?) but I can hardly imagine that an Apple-commitment would bring AMD to it's knees.
Maybe we mortals would have a hard time buying our single chips off the shelf for a while, but a true contention? Hm.
Re:I inadvertently switched to Intel...
on
Is AMD Dead Yet?
·
· Score: 2, Insightful
Uh, erm, what?
Did apple's market share explode just recently? AMD seems to be fairly capable of supplying various server- and desktop-vendors. Dell, HP and Sun come to mind.
I don't think that the "number of chips that apple requires" would be such a big deal for AMD.
Hm, sounds indeed horrible. But my expirience with codebases in such a shape is that they tend to become a timesink and it just won't stop.
What I'm seeing on the screenshots is basically a webapp and not so much else. Why not take the database schema (at least the sane part) and start from scratch with a state-of-the-art web framework (django, RoR or whatever fits your bill)?
I imagine security is a major concern for a POS-app and that usually cannot be retrofitted. For each bug you squished there may be two others still lingering elsewhere.
Well, just my thoughts. But I wouldn't feel comfortable to base my companies POS-system on some "inherited hack". I'd much rather use one that the maintainer is honestly proud of and that doesn't make my eyes bleed when I actually look at the code...
The F-14 Tomcat was just retired, after 30+ years in service.
And the interesting part is how these advanced military technologies slowly trickle down to the commercial/OSS sector. Parts of the F-14 operating system are now used for a popular java servlet engine.
And, just to add another datapoint, it wouldn't be hard to synchronize the bots to a common timesource and simply schedule your attack in advance. Think CronBot(tm).
When I look at the resolution of google earth (easy to make out cars or even humans) I imagine it must be trivial to locate a crashed plane in a known area, at least with military satellites. Maybe time intensive (I have no idea about their state of image processing) but isn't human life worth the effort?
So why aren't these used for search & rescue? How many airplane crashes are there, all over the world, every day?
Would it be too much asked to provide satellite aid in cases such as this or am I mistaken and it's really not possible?
There's no talk of perpetual motion. No whisper of broken scientific laws or free energy. Zahn would never go there - at least not yet. But he does see the potential for making electric motors more efficient, and this itself is no small feat.
So how do we get from that statement to the slashdot headline? Too much crack? Had a bad month in ad revenue?
Well, as I understand it cluster-filesystems such as GFS or GPFS (and likely others) can do that today. You basically tell them how many copies you want for redundancy and they make sure that all data is replicated at least that often.
I don't know about a viable windows implementation and I'm quite sure that these systems are not designed for nodes constantly entering and leaving the network - but still, the concept seems applicable.
I, too, find the whole idea intriguing, actually I'm sure there is a product idea hiding in there. One thing that immediately springs to my mind would be backup. With a high level of redundancy (5 or so?) and some mechanism to make sure that the copies are always distributed to the physically most separated hosts (so a burnt down building can not cause data loss) I could very well imagine this to become an interesting part of backup infrastructure.
Having 5 copies of all data may sound much at first but if we're talking about desktop nodes then there is not much data in first place. And even if some disk-only nodes need to be added to make the equation work then that would likely still be cheaper than all that highly-redundant and supposedly super-reliable backup-hardware that we're using today...
Slashdot Mirror
Hm, I'll go through them one by one.
Zones are indeed amazing but we don't have a use-case for them on our
production hosts. Maybe we could have used "zone-images" to deploy our
stuff but that'd really only be an excuse to use zones for a task
that seems to be better suited to apt (dependency tracking, controlled
distribution of updates etc.).
ZFS, no doubt, is something we miss.
SMF. Well, as often with solaris I love the concept but hate the implementation.
Yes, it beats sysv-init hands down. But, gah, XML, and many of the pkgs on solaris
freeware don't even support it yet. We learned how to roll our own pkgs (with SMF etc.)
but the lack of a package-manager akin to apt turned this into a time sink.
DTrace is a similar story. Ofcourse it is powerful but on a every day base we simply
don't need that power. We prefer the simplicity of strace which has, so far, been
good enough when we needed it and never forced us to wade through documentation
for supposedly "simple" tasks like dtrace did. Dtrace alone seems to be basically
useless until you wrap it up in a fairly elaborate script for the task at hand.
Yes, "DTraceToolkit" provides these scripts for many common tasks, but not for all.
Looking back at the first dtrace tutorial that I found (http://developers.sun.com/solaris/articles/dtrace_example.html?feed=DSC)
I can still only shake my head about the effort it takes for such a simple task.
About messing on the command line often: No, we don't need that "often" but regularly.
We install stuff, upgrade stuff, like everyone does. The major gripe was: We don't want
to repeat ourselves for n hosts. Ideally we want to roll packages and distribute them
in a controlled manner. Solaris left us out in the cold here and implementing a 3rd
party framework like puppet feels wrong when linux never even made you think about that.
No, pkgadd -d is not too hard for us. But manually downloading each dependency from solarisfreeware
or whatever source and installing it on each individual host is. Not too hard as in "we can't do it"
but too hard as in "dude, that feels backwards".
Feel free to enlighten me. How do *you* upgrade curl (random example) on 8 solaris hosts?
In debian we review the distro pkg and roll our own when necessary, test it, push it to the
mirror and the nightly update pulls it to all hosts. What tools did we miss that enable
an equivalent workflow for solaris?
Generally I wouldn't say we weren't able to handle solaris. I'd say it turned out we didn't *want* to.
It's very well possible that AIX would break us into a quivering goop. For that precise reason I have
no intention to ever touch it? It has nothing to offer that interests us, so why should I even
consider it?
Well and finally, your last statement makes you sound strikingly similar to the Sun sales reps
that we had. They also kept trumping the horn of "use our modern OS with features not
yet available for linux" to "utilize our kickass hardware to the fullest".
The problem probably lies in the definition of "utilizing our hardware to the fullest".
For you and Sun that probably means to squeeze out the last 10% of performance.
For us it means being able to fluidly run and maintain the hosts (that includes
a sane update-procedure etc.) with a minimum cost in terms of manhours.
In other words: The time we saved on "solaris administration overhead" since
we abandoned it quite likely paid our last 3 xfires alone.
You may blame it on our lack of solaris expirience or even on your perceived
"ineptitude". Still it was the right decision for us.
Funny. It has been exactly the opposite for us.
We're running a bunch of xfires (14 boxes total, 4100, 4200, 4150) here
and initially started out with solaris because the wise guys said it's faster,
more stable, oh and no least you get that shiny "platinum support" badge...
Yea it was all that and the zfs hype, what could possibly go wrong?
Nothing much to be honest. We fell in love with the hardware immediately
and the machines hummed along without too much trouble. Postgres performs
well, java performs well, and ZFS snapshots are a blessing.
Despite all that superficial happyness we switched most of the hosts to linux
(and aim for 100% linux) after a few months. We still love ZFS (and can't wait
for a linux equivalent) but that alone couldn't justify sticking to solaris for us.
What broke it for us is the userland with all its subtle differences
to linux, or in other words: the learning curve. This may sound strange when
talking about a UNIX OS but as a linux shop we're spoiled by the GNU toolchain,
by dead-simple package management and all the little everyday things that just
work a tiny little bit different under solaris.
I'm not saying the linux-UI is better (actually, it is in many
places, but that's not the point here), it's just that we all grew
up with linux, so the solaris CLI "felt like a really old version of linux"
(to paraphrase a coworker) from the start.
We didn't slack, mind you. We tried hard to make that feeling stop. We read the
books and collected bigadmin bookmarks like trophies. We changed the default-shell
to bash and installed the GNU tools to keep our sanity but otherwise did our best
to treat solaris with respect and resisted the urge to dress it up to look more
like linux.
It didn't work out.
I could rant for days about the many little things that drove us away but
I'll try to focus on a few of the most significant points here:
1. Package Management (the lack thereof)
Pkg-add is bad joke when you're used to apt-get and emerge. JumpStart feels
like an insult when you're spoiled by FAI. I can only guess how Sun expects
us to keep our multiple solaris boxes in sync. Maybe they sell that as
one of their many enterprise service?
2. Google doesn't work well for solaris
Not really something we can blame on solaris or Sun but time after time we
were astonished as to how hard it is to find useful help for specific solaris
problems via google. Howto's and Tutorials about all things solaris are generally
very sparse. Due to this "learning by doing" doesn't work as well for solaris
as it does for linux.
3. The sun website SUCKS
Sure there is a lot of documentation, if you can find it in the pile
of rubble that sun calls a website. But even the stuff we found was
not always helpful. Sun documentation tends to be very verbose while
still often glossing over important details. Sun docs often feel like
they expect you to print them out and put them under your pillow.
We don't work that way. We're spoiled by straighforward howtos,
examples, stuff that gets us going fast. We're the impatient
youngsters.
Well, this got longer than I intended. I'll close with saying that
we'll keep buying sun hardware. The xfire series is the best piece of kit
(at a very competitive price) that I have ever seen and it runs linux
like a champ.
But linux as an "upgrade path to solaris"? Ha. Good joke.
In my world solaris has it's place on big iron and in areas where
the last bit of performance really matters. For everyone else the
natural choice is what they're familar with. And who grows up with
solaris these days?
Yep, they have amazing hardware at *excellent* prices, too.
I don't give a damn for solaris or any sun software but their xfire series
is the best bang for buck you can buy these days.
I don't think GP's analogy was all off.
At least not more than your all-you-can-eat analogy is off...
Maybe we should just try to do without analogies at all?
Here's my take:
R&D happens all the time, technology is evolving.
Networking equipment becomes faster and cheaper every day, this applies
not only to your ethernet PCI-card but also to the big honking router
equipment that ISPs use.
It is not more expensive to provide you with an 10MBit/s uplink today
than it was to provide you with a 2MBit/s uplink a few years back.
The equipment for that costs roughly the same, it simply utilizes
the existing physical infrastructure better.
Ofcourse there are physical limits to what you can push through
the last mile or through a deepsea cable.
If ISPs were seriously worried that all those VDSL last-mile customers
may eventually saturate the backbone then, doh, how about stop selling VDSL
for a while? Or throttling it? At least until it becomes financially feasible
to upgrade those backbone lines?
The whole "Gah, the internets will explode"-fud is just nonsense.
*If* the backbones become saturated then a very simple thing will happen:
Last-mile bandwidth prices will increase. The rich will get the fast links,
the poor will be stuck with whatever is considered "slow" at that point in time.
How is that any different to what we have today?
$20 mio is pocket change for intel. If that's really all they put into
research of parallel computing then that doesn't seem to rank so high
on their priority list.
Wouldn't surprise me as the market for parallel computing is fairly small
(HPC) when compared to the cash cow sectors (server, consumer).
I think the article is hyperbole. There isn't much need in those
latter markets for parallelism at the hardware level because only
few tasks can be parallelized at that level.
Hell yea!
I squirm whenever I read about all the manyears they
constantly throw at refactoring the blackhole that is the
mozilla codebase.
Really, how long can it take to write a new browser from scratch?
I'm not saying that it's not a serious undertaking but I would really
love to see what all those skilled mozilla devs could achieve if
all the legacy crap was suddenly taken off their shoulders...
Better yet, I'm sure that not all parts are broken beyond salvation.
Why not cherrypick the good stuff (and *only* the good stuff) and build
your new world around it!
Large parts of gecko could likely survive the transition.
Same for the JS engine of choice. Everything UI would have to go
(remember: XUL was originally meant as a practical joke) but that
part is not so hard to reinvent better.
6 years ago? Wow!
Everytime I leave a beer in our fridge it's either gone within
two days or magically transformed into a dollar-bill.
Well, you're painting it very black & white while in reality it is many shades of gray.
Yes, XP drivers are "pretty good" but so are linux drivers these days.
Also you don't need the CLI for everyday tasks in a modern distro anymore.
The GUI frontends are improving and if you're literally spending your time in
firefox, openoffice etc. then there's just no need to drop to CLI - just as there
is no need in XP.
Further, if you really consider tracking down registry entries any better
or easier than working with a CLI then I guess many people would beg to disagree
Well, I only came in to clear up your misconception about DOS being anything like a unix shell.
Not to draw you over to linux or anything.
The whole hardware-support story is an old hat. It basically boils down to: If you want to use linux
then buy hardware that's supported by linux. Which, for the majority of peripherals, is not hard anymore.
Google for "$name_of_my_gadget linux" in advance and in 90% of cases you'll learn that it runs without
problems.
Furthermore it's also an old hat that the driver-situation in windows is not flawless either.
Yes, you get a pretty GUI, but if the pretty installer fails then you're SOL.
Even if you wanted to tinker - there is no ndiswrapper to try, no kernel options to tweak
and usually no alternative source for drivers either. If your old $whatever is not supported
in vista - tough luck. Not even an uber-user can help you there.
So, finally, to each it's own. You prefer the GUI, so stick with what you like.
But don't label yourself as the prototype of an "end-user". I know quite a few "end-users",
especially of the technically clueless type, who have quite happily switched to linux
recently. If really all you want to do is browse the web and do a bit of office work (without
touching a command line) then an ubuntu box can serve you well and in fact *save* you quite
a bit of trouble with regard to "tweaking the personal firewall", re-installing after trojan infections,
re-installing after a windows update screwed up your drivers or re-installing after your office
began to behave wierd for no obvious reason.
DOS != unix.
You're not re-learning DOS when you switch to linux.
Instead you're learning a true unix shell. Which gives you
access to a large library of insanely powerful, time-tested
commands that can be combined in an uncountable number of ways.
Those not only enable you to solve a large number of problems
(actually whole categories of problems) quicker and more reliable
than any GUI could but they further enable you to automate your
solutions for re-use.
What may seem "inconvenient" at first is your first
glimpse at the power of UNIX.
Don't discard it so quickly because it's only white text on
a black screen and "looks like DOS". It's not DOS.
He doesn't need to. The login credentials were in the subject line. He could just scrap them off the web interface
without clicking on a mail or (more likely) use the POP3/IMAP LIST command to fetch the list, again without
actually reading a mail.
Furthermore I know for sure that imap (and i guess pop3, too) has a command to mark a mail as unread again.
Benefit of the doubt?
For what "debugging purpose" should this program send a copy of all passwords anywhere?
Think about what it actually does: It logs into gmail and copies all your mail to somewhere else.
There is no reason for any developer or user to ever care to see the password!
And even if there *was* a valid reason to do so: Why send it out by e-mail (many lines of code)
instead of just displaying it in a popup-dialog (one line of code)?
Long story short: There is no benefit of the doubt here.
This "feature" was put in deliberately for the single, malicious purpose
of collecting other people's gmail passwords. And, to top it off, he even
*sold* the software for real money. Someone should sue this guy into oblivion...
Yes, solaris is a bitch. Has been that way forever and will probably stay that way for a while.
But the argument was about performance and that is the precise and primary reason why so many
people still bother with the "ugly bully".
BSD and linux fanboys arguing about "performance crowns" sounds like kart-racers
arguing about "who has the fastest car in the world" to me.
It's cute to watch but sometimes I just can't resist...
bind?
ugh. is that piece of crap *still* not dead?
i thought everybody and their dog had switched to tinydns & co by now...
Ehm, *which* crown?
Last time I checked most performance crowns were worn by solaris.
Well, I cannot say that I'm deeply involved with the numbers game
but these figures from AppleInsider seem to suggest
that Apple's share, while significant, is not even in the same ballpark as Dell or HP.
Even if only 25% of the Dell's are shipped with AMD CPUs that would still be more
than all of Apple. As said, I have no idea about the actual figures (maybe Dell sells
only 1% AMD?) but I can hardly imagine that an Apple-commitment would bring AMD to it's knees.
Maybe we mortals would have a hard time buying our single chips off the shelf for a while,
but a true contention? Hm.
Uh, erm, what?
Did apple's market share explode just recently?
AMD seems to be fairly capable of supplying various server-
and desktop-vendors. Dell, HP and Sun come to mind.
I don't think that the "number of chips that apple requires"
would be such a big deal for AMD.
Hm, sounds indeed horrible.
But my expirience with codebases in such a shape is that they tend
to become a timesink and it just won't stop.
What I'm seeing on the screenshots is basically a webapp and not so much else.
Why not take the database schema (at least the sane part) and start from scratch
with a state-of-the-art web framework (django, RoR or whatever fits your bill)?
I imagine security is a major concern for a POS-app and that usually cannot
be retrofitted. For each bug you squished there may be two others still
lingering elsewhere.
Well, just my thoughts. But I wouldn't feel comfortable to base my
companies POS-system on some "inherited hack". I'd much rather use one
that the maintainer is honestly proud of and that doesn't make my eyes
bleed when I actually look at the code...
And the interesting part is how these advanced military technologies slowly trickle down
to the commercial/OSS sector. Parts of the F-14 operating system are now used for
a popular java servlet engine.
Just curious: If SQL-Ledger was so horrible then why did you fork it instead of starting from scratch?
There it is. The oldest known application of "agile methods".
And we thought the internet companies of today were the first to fall into that trap...
And, just to add another datapoint, it wouldn't be hard to synchronize the bots to a common timesource
and simply schedule your attack in advance. Think CronBot(tm).
What about satellites?
When I look at the resolution of google earth (easy to make out cars or even humans)
I imagine it must be trivial to locate a crashed plane in a known area, at least
with military satellites. Maybe time intensive (I have no idea about their state
of image processing) but isn't human life worth the effort?
So why aren't these used for search & rescue?
How many airplane crashes are there, all over the world, every day?
Would it be too much asked to provide satellite aid in cases such
as this or am I mistaken and it's really not possible?
So how do we get from that statement to the slashdot headline?
Too much crack? Had a bad month in ad revenue?
Well, as I understand it cluster-filesystems such as GFS or GPFS (and likely others) can do that today.
You basically tell them how many copies you want for redundancy and they make sure that all data
is replicated at least that often.
I don't know about a viable windows implementation and I'm quite sure that these systems are not
designed for nodes constantly entering and leaving the network - but still, the concept seems applicable.
I, too, find the whole idea intriguing, actually I'm sure there is a product idea hiding in there.
One thing that immediately springs to my mind would be backup. With a high level of redundancy (5 or so?)
and some mechanism to make sure that the copies are always distributed to the physically most
separated hosts (so a burnt down building can not cause data loss) I could very well imagine
this to become an interesting part of backup infrastructure.
Having 5 copies of all data may sound much at first but if we're talking about desktop nodes
then there is not much data in first place. And even if some disk-only nodes need to be added
to make the equation work then that would likely still be cheaper than all that highly-redundant
and supposedly super-reliable backup-hardware that we're using today...