Allow me to state that all of the port maintainers I've interacted with are very friendly and helpful. I've had some of my ports and port patches sucked into the mainline ports tree in under 24 hours.
I love FreeBSD. It is a great community that values stability over flashiness and features. Everything is documented as a man page, and if you get lost, FreeBSD.org is your portal (as apposed to linux, where the question "where do I even start" is a big one).
My only fear is that people try to turn FreeBSD into something that competes with linux "for the desktop". As far as I'm concerned, FreeBSD is the perfect OS for a server and trying to "go for the desktop" can only load it up with baggage for graphics, sound and other things that doesn't matter for servers.
So, my ebay rating for FreeBSD? A+++++++++++++++ Would use Again!
When you are getting your ass sued you dont go around deleting (or hiding) anything that relates to the case. That is what Torrentspy did. They got sued, and while the lawsuit was in progress, they deleted and hid evidence.
TorrentSpy might have won the case and they still might. But now they've got a different problem... they tampered with evidence. Correct me if I'm wrong, but that is a pretty serious *crime* (not a civil suit). They could go to pound-me-in-the-ass penitentiary for that one.
Dividing up the namespace by language is the perfect solution. I love it!
I suspect the biggest "problem" will be slop. Parrot cannot tolerate slop from languages. MSIL lays out some pretty important requirements before you can join the MSIL club. For example, if you want to compile C++ to "Safe MSIL", you cannot use the c++ standard library, you cannot use malloc/free, new/delete, or pointers. You've got to instantiate your stuff with gcnew. You can't use native data types, you have to use the.NET ones. And it has to be that way because otherwise you'd have a mess when you call the whole thing from C# or IronPython. That is the beauty of MSIL and.NET - as long as everybody agrees to the rules about what a string is, how inheritance works and how functions and objects behave, the party can go on and on.
As long as parrot requires some baseline functionally before you can join the club, life will be okay. What would suck is if I wrote something in perl that spat out a hashref into the world that wasn't able to get sucked up by another language in the club. Or I wrote a PHP function targeted to parrot that wouldn't work in your scheme-like language. If that was the case, each CPAN or PEAR library would start to have a list of supported languages. On MSIL and.NET, I know that my language plays by the rules, my library will work anywhere. It is the "If $LANGUAGE_X supports a keyed lookup operation, then..." that makes me nervous. How can I test that if there is no defined behavior?
How does parrot deal with calling external libraries (dll's or so's)?
Maybe my flaw is I'm thinking parrot is something it isn't. Does it even make sense to compare it to MSIL/.NET? If it doesn't, I suspect it should be stressed so we stop trying to apply it to where it doesn't belong:-)
This is a dead thread but...
Malware is big business, so companies profiting from malware will simply buy certificates for their rootkits. True.dat.
The cert authority can revoke the certificate though right? probably not until it expires, right?
Either way, it is an expensive hurdle for script kiddie botnets to leap over. A blessed botnet.exe suddenly becomes something only organized crime can acquire (that is, unless the cert authority is hacked by the script kiddie botnet owner:-)
they are pushing it as a way to exclude independent developers That is one way to interpret it. I dont agree they are out to deliberately screw developers, even if that is the result. I think they are doing it to bring some kind of accountability to the table.
I suspect we'll see some non-profit organization provide code certificates to trusted applications. I'd also assert that you have no business distributing software to random people if you cannot afford the certificate. That is a big assertion though, and I dont entirely belive it myself. I'm thinking contractors (like myself) and custom applications for "mom and pop" break my bold assertion. I will assert shareware apps you download from "download.com" should all be signed, period. Regardless, we are in a very grey area on how to define what should be signed and shouldn't, aren't we:-)
So the question becomes, do certificates provide *any* measurable win? I'd say yes. I'd also say your objections are valid as well. Does the win outweigh the cost? I dont know.
And to answer some of my questions... here is the FM. The docs actually define a bit about how namespaces (should?) work as well as other things I left out on my list like threading.
First, I've been meaning to buy your perl testing book.
Second,
what is in it for me? Why should I care?
If I'm PHP, why should I compile to PIR?
What is the fundamental "unit" of a library/application compiled in PIR. In.NET you deal in assemblies. In PIR, what do you deal in?
Where is the boundary between something written in PHP and something in Perl? Is it a function? A class? A module?
How does PIR handle the clash between objects and classes? Can I pass a blessed object created in perl to my PHP app?
What about namespace issues and how does PIR reconcile against language that have piss poor namespace support like PHP?
What about all the cool hashtable/hashref stuff that perl has? How will that work on something like PHP?
What about inheritance? Can I derive a class in perl from a class written in Ruby?
What about debugging? If something chokes in my PHP library, will parrot let me see the PHP symbol table AND my python symbol table?
How will any of this be useful without a very smart IDE? It is hard enough to keep track of large applications written in Perl because of the lacking tool support. If I'm calling a function/assembly written in PHP, am I now going to have to hop between to languages to figure it all out?
What is the baseline "your language needs to support XYZ before it works in PIR"? Or is this thing so low, the only thing I can bank on is a string? Does it define, for example, how and when a string might get cast as an integer?
In Perl a variable ($var) set to "", undef or "0" all equate to false in: unless( $var ) {// i'm here if $var is "", undef or "0" } Does the PIR dictate other languages interpret a variable the same way? If not, how do I as a program deal with this?
In Perl, subroutines get their variables typically by using: sub {
my $var1=shift;
my $var2=shift;
my $var3=shift; }
Other languages usually declare their subroutines formally: function($var1, $var2, $var3){//code }
How does PIR reconcile this very big difference?
This isn't a diss. What I asked above I think is a very reasonable set of questions and expectations. I'm very curious what the sales pitch is because if it worked correctly, it could be very cool.
It's goal is to be a general VM that any language can run on. Sorry. That has been done. See Mono, MSIL and.NET.
I love perl dearly, but if they think people are going to write language compilers on top of their VM stack, I've got a bridge to sell. The VM market will be locked up tigher than a nuns hoo-haa before perl pushes out anything to compete.
And who cares anyway? The reason MSIL is taking off is the rich API that.NET offers. What API is perl going to bring to the table that can compete with.NET? If you say CPAN, that is a good answer, but why am I going to write PHP on top of a CPAN module when I can just write perl on top?
A flaw that is only locally exploitable, even if it can give the attacker a full root shell if used, is of much less importance than one that can zombie a machine remotely. To say local exploits are of much less importance than remote ones is the absolute biggest lie I ever read here on slashdot!
True, local exploits might not be as important on a server that doesn't have anybody on it, but on the desktop where everybody is local, they are a HUGE HUGE issue. They are even more of a problem than remote exploits because most home users run inside a NAT and usually dont get hit directly with portscans.
All it takes to make a remote exploit out of a local exploit is one email with "mouse-on-the-screen.exe" or a single download of "happy-cat-chases-your-cursor-around-the-screen.exe".
Please don't ever spread the lie that local exploits aren't important!
It's pretty rare that security updates in the Linux world break the operation of the machine. In my experience, this really, really, really depends on the distro and how they manage "third party packages". If your running Gentoo, security patches don't often get backported. Typically, the only way to fix a security issue is upgrading the software version and all it's dependencies.
Even on my beloved FreeBSD, the only part of the OS that gets backported security fixes is the core. Thankfully, the "core" of freebsd is much bigger than the linux core, which is only the kernel. Most of the ports dont get backports on FreeBSD either, but there are some very large exceptions to this, like apache, mysql, postgres, etc.
So yeah. I guess the only people who have really nailed this is debian or maybe redhat. I'd say the biggest difference between distros *is* how they manage backports.
Don't forget patch Tuesday isn't a hard and fast rule. If there is a nasty vulnerability with code already in the wild that exploits it, Microsoft obviously isn't just going to go soup nazi on your ass and say "no patch for you! come back on Tuesday!". They'll push out a critical fix as soon as they can and you better damn well deploy it across the organization.
If there is no (known) code in the wild that exploits a security vulnerability, it makes much more sense to push out the fix on a routine schedule (for all the reasons given in the parent post). Once they push out a patch, people will reverse engineer it and *write* code to exploit the vulnerability.
Your printer sounds fucked up. That is not an example of a legitimate UAC dialog. Nor is that Vista's problem. Talk to your idiot sysadmin or talk to the idiots who wrote the printer driver.
If you are getting UAC dialogs to print, you've got bigger problems with your computer than Vista. I always wonder if these "100 UAC a day" people have spyware that was happily running on the XP box they just got done upgrading from?
Oooo... dont forget that almost all new thinkpads have thumbprint readers. Imagine if thumbprint readers became widespread and were on the side of your LCD, or on your keyboard? Imagine if you had to give your fingerprint to click through a UAC dialog?
Something about myporn.exe and fingerprint readers though... I dunno:-)
Name a single UAC dialog that wasn't for a good reason. Just one.
Most UAC problems are either the fault of the software vendor being an idiot, or the result of poor UAC integration (I'm looking at you notepad and all the common file dialog boxes, why can't I get a UAC dialog instead of a "permission denied" message?).
You could also say that Vista and windows has a weaker architecture that requires more things to be locked up as root. Most OSX programs are installed on the users desktop or in their extended home directory, right? In that case, you don't need to be elevated to muck around with the application as the files are all owned by you. I dont know if that is a good thing or a bad thing really. It is just different.
i haven't used vista much It shows;-) You should play with it a bit more. The admin group on vista is kinda-maybe-sorta like what the wheel group is on a BSDish unix system. You aren't running as root, but you are in a group that can su to it if you want. The admin group on XP had you quite literally running as root. Local users on Vista need somebody in the wheel group to use their credentials to get past a UAC dialog. I forget what it was on XP, but I dont think you could ever run elevated without logging out and in as an admin first (which is why nobody ever ran as a limited user:-)
I still agree with you; on vista, social engineering will become the best root exploit. The good thing is it is hard to fake a UAC dialog and the only way something other than a user can confirm one is via a root exploit. Like you, I can imagine these download sites telling the user "just ignore the UAC that pops up, you can trust us...". As you see already, there are plenty of idiots running around disabling UAC on their computer. (I hope to god they aren't disabling on computers they do not personally own - that is so irresponsible I don't know what to say).
The first big virus that hits vista will result in media all across the globe telling people "dont randomly click through UAC dialogs you idiots!". I remember the slammer or whatever and our local news would always tell you "never run untrusted programs on your computer" at the end of the newscast. Same thing will happen with Vista.
Wanna really make Vista secure? Make it a requirement to sign your binary with a legit code certificate. Refuse to run it at all unless it is signed. I'll bet money we see that in the next couple versions of windows. The question is how do we sign *legitimate, trusted* open source apps? I suspect we'll figure it out.
Do you even know how botnets work I know how they work. But some of the tricks they used to rely on aren't as easy in Vista. There will still be idiots who click through UAC's to see "myporn.exe" no matter what. But the fact that "myporn.exe" used to run without *any* kind of warning to the user is what I think the big deal is.
I believe the number of "I run any executable" people is way higher than the number of "I click through scary operating system messages" people. If 1,000 people run myporn.exe, but only 10% of them click through the UAC and get botted, that is a huge improvement over XP! On XP, all 1,000 myporn.exe users got the bot, but only 100 of the myporn.exe users on Vista got the bot. See where I'm going? You still have 100 people running the myporn.exe bot, but it is way better than the 1,000 you could have had.
The question becomes, is my 10% guess high or low?
How about any open source imap client for that matter?
There used to be some IMAP to WAP client based on PHP, but it had all kinds of crazy problems like you had to hardcode your login to the config file. It also was read only - you couldn't send mail from the phone.
Is there anything new on the market for mobile users?
Roundcube has great potential, but it isn't nearly as mature as SM. It does seem to be getting better though. The big problem I have with Roundcube is it doesn't have plugins. No plugins = no Sieve filters (avelsieve), which is a big deal to me. No plugins = no other cool things that Squirrelmail has like importing and exporting address books from all kinds of crazy places, no admin plugins, etc...
Someday though. It has always looked and functioned way nicer than squirrelmail, it just needs more backend sysadmin goodness.
Sure they can talk out port 25 all they like, but your virus scanner is running as root. One of the first things a good botnet program does is disable the virus detection software. They can't do that anymore.
Botnets might be able to sniff your files, but they can't sniff your keyboard without running as root.
Yeah... and I've got a bridge to sell you:p SP1 reduces some of the more stupid popups so the statement is nearly true It does have it's share of seemingly stupid popups, better to be stupid and to frequent than lax and never. For example, a normal user shouldn't be mucking with directories outside his home directory (program files), so it should pop a UAC up. A lot of the others are from stupid software trying to mess with said directories as a normal user. I think the trick is a more elegant way to elevate yourself while in file explorer (and friggen make notepad.exe aware of UAC!). The hard part is if Microsoft makes it easy for you, it becomes easy to exploit by evil software. Anything you can do, a script can do.
Bottom line is yeah, botnets can live on a Vista box, but their life just got way, way harder. Maybe you should say "botnets can live on Vista, but probably for a short amount of time before getting discovered and cleaned up". Or something...
It will be interesting to see how botnets evolve to deal with Vista. What kinds of evil things can they do on a limited user account? Can they get your IE/Firefox passwords? Dunno. Can they sniff packets sent out by the user they are running under? Dunno, but I doubt it. Can they sniff my trillian chatlogs? Hell yeah. Can they sniff my saved IMAP password in outlook? Dunno.
It will be an interesting 2008, that is for sure. Vista is the first Microsoft OS that will not have ordinary users running as root. If spyware or botnet software wants to sink into Vista, it either has to go through a UAC dialog first, or do it the old fashioned way through a root exploit.
Idiots will always click through UAC dialogs unthinkingly (or worse dumb geeks will turn UAC off completely and run as root like on XP). UAC pops up only when you expect it to, the button or icon will have a shield on it. UAC should never pop up out of the blue, which would happen with a evil program trying to do bad things. I suspect even the greatest of idiot will think twice before hitting okay on a random UAC dialog.
The interesting question is how many privilege escalation exploits will be found on Vista? How long will it take to get those patched? How wide will any botnet program spread using the exploit?
The other interesting thing to track is if there will be a decline in botnet size equal to the rise in Vista installs.
You know what sucks more than Vista? Linux! And the best parts is, Linux isn't even worth it's price and it is free! How do you like those apples? Linux cannot even compete when it is free! The only reason it is more popular than FreeBSD or OpenBSD is because of paid shills like you. Which is a shame, because FreeBSD is a much more stable, well documented system.
My Question for you, Mr. Raven is how do you get paid by the FSF to make these comments when your whole damn operating system is free!?
Of course, I'm joking about the paid shills (maybe) but I'm serious about linux (for all values of $DISTRO) being a shitty operating system. FreeBSD is far better. Vista is much better than them on, at least on the desktop.
Yup. You nailed it. Anybody who likes a Microsoft product is clearly a shill for Microsoft. I am clearly paid by Microsoft to make these comments. You got it. Sorry for the mistake.
Come to think of it, maybe you are the one getting paid by the Apple to post your comments. Why don't you go talk to *your* manager at apple and ask for a raise? Maybe you should quit your job at Apple and go work for RMS at the FSF. I hear they pay real great to shill the Hurd. I've heard he even flies first class when he makes trips to paris for uninvited visits to important officials. You damn shill... get back to making GNOME not suck or something...
Allow me to state that all of the port maintainers I've interacted with are very friendly and helpful. I've had some of my ports and port patches sucked into the mainline ports tree in under 24 hours.
I love FreeBSD. It is a great community that values stability over flashiness and features. Everything is documented as a man page, and if you get lost, FreeBSD.org is your portal (as apposed to linux, where the question "where do I even start" is a big one).
My only fear is that people try to turn FreeBSD into something that competes with linux "for the desktop". As far as I'm concerned, FreeBSD is the perfect OS for a server and trying to "go for the desktop" can only load it up with baggage for graphics, sound and other things that doesn't matter for servers.
So, my ebay rating for FreeBSD?
A+++++++++++++++ Would use Again!
When you are getting your ass sued you dont go around deleting (or hiding) anything that relates to the case. That is what Torrentspy did. They got sued, and while the lawsuit was in progress, they deleted and hid evidence.
TorrentSpy might have won the case and they still might. But now they've got a different problem... they tampered with evidence. Correct me if I'm wrong, but that is a pretty serious *crime* (not a civil suit). They could go to pound-me-in-the-ass penitentiary for that one.
Moral: Think before opening your trap.
Bah! See, I answer my own questions. how to make native calls.
:-)
I love perl. Everything is documented, you just have to know where to look
Sweet. Thanks for the reply.
.NET ones. And it has to be that way because otherwise you'd have a mess when you call the whole thing from C# or IronPython. That is the beauty of MSIL and .NET - as long as everybody agrees to the rules about what a string is, how inheritance works and how functions and objects behave, the party can go on and on.
.NET, I know that my language plays by the rules, my library will work anywhere. It is the "If $LANGUAGE_X supports a keyed lookup operation, then..." that makes me nervous. How can I test that if there is no defined behavior?
:-)
Dividing up the namespace by language is the perfect solution. I love it!
I suspect the biggest "problem" will be slop. Parrot cannot tolerate slop from languages. MSIL lays out some pretty important requirements before you can join the MSIL club. For example, if you want to compile C++ to "Safe MSIL", you cannot use the c++ standard library, you cannot use malloc/free, new/delete, or pointers. You've got to instantiate your stuff with gcnew. You can't use native data types, you have to use the
As long as parrot requires some baseline functionally before you can join the club, life will be okay. What would suck is if I wrote something in perl that spat out a hashref into the world that wasn't able to get sucked up by another language in the club. Or I wrote a PHP function targeted to parrot that wouldn't work in your scheme-like language. If that was the case, each CPAN or PEAR library would start to have a list of supported languages. On MSIL and
How does parrot deal with calling external libraries (dll's or so's)?
Maybe my flaw is I'm thinking parrot is something it isn't. Does it even make sense to compare it to MSIL/.NET? If it doesn't, I suspect it should be stressed so we stop trying to apply it to where it doesn't belong
Thanks!
The cert authority can revoke the certificate though right? probably not until it expires, right?
Either way, it is an expensive hurdle for script kiddie botnets to leap over. A blessed botnet.exe suddenly becomes something only organized crime can acquire (that is, unless the cert authority is hacked by the script kiddie botnet owner
I suspect we'll see some non-profit organization provide code certificates to trusted applications. I'd also assert that you have no business distributing software to random people if you cannot afford the certificate. That is a big assertion though, and I dont entirely belive it myself. I'm thinking contractors (like myself) and custom applications for "mom and pop" break my bold assertion. I will assert shareware apps you download from "download.com" should all be signed, period. Regardless, we are in a very grey area on how to define what should be signed and shouldn't, aren't we
So the question becomes, do certificates provide *any* measurable win? I'd say yes. I'd also say your objections are valid as well. Does the win outweigh the cost? I dont know.
And to answer some of my questions... here is the FM. The docs actually define a bit about how namespaces (should?) work as well as other things I left out on my list like threading.
Second,
unless( $var ) {
}
Does the PIR dictate other languages interpret a variable the same way? If not, how do I as a program deal with this?
sub {
my $var1=shift;
my $var2=shift;
my $var3=shift;
}
Other languages usually declare their subroutines formally:
function($var1, $var2, $var3){
}
How does PIR reconcile this very big difference?
This isn't a diss. What I asked above I think is a very reasonable set of questions and expectations. I'm very curious what the sales pitch is because if it worked correctly, it could be very cool.
I love perl dearly, but if they think people are going to write language compilers on top of their VM stack, I've got a bridge to sell. The VM market will be locked up tigher than a nuns hoo-haa before perl pushes out anything to compete.
And who cares anyway? The reason MSIL is taking off is the rich API that
Whatever dude. Printers don't trigger UAC dialogs. IHBT.
True, local exploits might not be as important on a server that doesn't have anybody on it, but on the desktop where everybody is local, they are a HUGE HUGE issue. They are even more of a problem than remote exploits because most home users run inside a NAT and usually dont get hit directly with portscans.
All it takes to make a remote exploit out of a local exploit is one email with "mouse-on-the-screen.exe" or a single download of "happy-cat-chases-your-cursor-around-the-screen.exe".
Please don't ever spread the lie that local exploits aren't important!
Even on my beloved FreeBSD, the only part of the OS that gets backported security fixes is the core. Thankfully, the "core" of freebsd is much bigger than the linux core, which is only the kernel. Most of the ports dont get backports on FreeBSD either, but there are some very large exceptions to this, like apache, mysql, postgres, etc.
So yeah. I guess the only people who have really nailed this is debian or maybe redhat. I'd say the biggest difference between distros *is* how they manage backports.
Don't forget patch Tuesday isn't a hard and fast rule. If there is a nasty vulnerability with code already in the wild that exploits it, Microsoft obviously isn't just going to go soup nazi on your ass and say "no patch for you! come back on Tuesday!". They'll push out a critical fix as soon as they can and you better damn well deploy it across the organization.
If there is no (known) code in the wild that exploits a security vulnerability, it makes much more sense to push out the fix on a routine schedule (for all the reasons given in the parent post). Once they push out a patch, people will reverse engineer it and *write* code to exploit the vulnerability.
So have I been trolled yet?
Your printer sounds fucked up. That is not an example of a legitimate UAC dialog. Nor is that Vista's problem. Talk to your idiot sysadmin or talk to the idiots who wrote the printer driver.
If you are getting UAC dialogs to print, you've got bigger problems with your computer than Vista. I always wonder if these "100 UAC a day" people have spyware that was happily running on the XP box they just got done upgrading from?
Oooo... dont forget that almost all new thinkpads have thumbprint readers. Imagine if thumbprint readers became widespread and were on the side of your LCD, or on your keyboard? Imagine if you had to give your fingerprint to click through a UAC dialog?
:-)
Something about myporn.exe and fingerprint readers though... I dunno
Name a single UAC dialog that wasn't for a good reason. Just one.
Most UAC problems are either the fault of the software vendor being an idiot, or the result of poor UAC integration (I'm looking at you notepad and all the common file dialog boxes, why can't I get a UAC dialog instead of a "permission denied" message?).
You could also say that Vista and windows has a weaker architecture that requires more things to be locked up as root. Most OSX programs are installed on the users desktop or in their extended home directory, right? In that case, you don't need to be elevated to muck around with the application as the files are all owned by you. I dont know if that is a good thing or a bad thing really. It is just different.
I still agree with you; on vista, social engineering will become the best root exploit. The good thing is it is hard to fake a UAC dialog and the only way something other than a user can confirm one is via a root exploit. Like you, I can imagine these download sites telling the user "just ignore the UAC that pops up, you can trust us...". As you see already, there are plenty of idiots running around disabling UAC on their computer. (I hope to god they aren't disabling on computers they do not personally own - that is so irresponsible I don't know what to say).
The first big virus that hits vista will result in media all across the globe telling people "dont randomly click through UAC dialogs you idiots!". I remember the slammer or whatever and our local news would always tell you "never run untrusted programs on your computer" at the end of the newscast. Same thing will happen with Vista.
Wanna really make Vista secure? Make it a requirement to sign your binary with a legit code certificate. Refuse to run it at all unless it is signed. I'll bet money we see that in the next couple versions of windows. The question is how do we sign *legitimate, trusted* open source apps? I suspect we'll figure it out.
I believe the number of "I run any executable" people is way higher than the number of "I click through scary operating system messages" people. If 1,000 people run myporn.exe, but only 10% of them click through the UAC and get botted, that is a huge improvement over XP! On XP, all 1,000 myporn.exe users got the bot, but only 100 of the myporn.exe users on Vista got the bot. See where I'm going? You still have 100 people running the myporn.exe bot, but it is way better than the 1,000 you could have had.
The question becomes, is my 10% guess high or low?
How about any open source imap client for that matter?
There used to be some IMAP to WAP client based on PHP, but it had all kinds of crazy problems like you had to hardcode your login to the config file. It also was read only - you couldn't send mail from the phone.
Is there anything new on the market for mobile users?
Why is this modded as a troll?
Roundcube has great potential, but it isn't nearly as mature as SM. It does seem to be getting better though. The big problem I have with Roundcube is it doesn't have plugins. No plugins = no Sieve filters (avelsieve), which is a big deal to me. No plugins = no other cool things that Squirrelmail has like importing and exporting address books from all kinds of crazy places, no admin plugins, etc...
Someday though. It has always looked and functioned way nicer than squirrelmail, it just needs more backend sysadmin goodness.
Botnets might be able to sniff your files, but they can't sniff your keyboard without running as root. Yeah... and I've got a bridge to sell you
Bottom line is yeah, botnets can live on a Vista box, but their life just got way, way harder. Maybe you should say "botnets can live on Vista, but probably for a short amount of time before getting discovered and cleaned up". Or something...
It will be interesting to see how botnets evolve to deal with Vista. What kinds of evil things can they do on a limited user account? Can they get your IE/Firefox passwords? Dunno. Can they sniff packets sent out by the user they are running under? Dunno, but I doubt it. Can they sniff my trillian chatlogs? Hell yeah. Can they sniff my saved IMAP password in outlook? Dunno.
Exciting and yet scary.
It will be an interesting 2008, that is for sure. Vista is the first Microsoft OS that will not have ordinary users running as root. If spyware or botnet software wants to sink into Vista, it either has to go through a UAC dialog first, or do it the old fashioned way through a root exploit.
Idiots will always click through UAC dialogs unthinkingly (or worse dumb geeks will turn UAC off completely and run as root like on XP). UAC pops up only when you expect it to, the button or icon will have a shield on it. UAC should never pop up out of the blue, which would happen with a evil program trying to do bad things. I suspect even the greatest of idiot will think twice before hitting okay on a random UAC dialog.
The interesting question is how many privilege escalation exploits will be found on Vista? How long will it take to get those patched? How wide will any botnet program spread using the exploit?
The other interesting thing to track is if there will be a decline in botnet size equal to the rise in Vista installs.
Good times ahead!
Indeed. At least on the best buy side of the fence you are correct. I couldn't imagine running vista on 512mb of ram.
Fair game Mr. Raven Sir,
You know what sucks more than Vista? Linux! And the best parts is, Linux isn't even worth it's price and it is free! How do you like those apples? Linux cannot even compete when it is free! The only reason it is more popular than FreeBSD or OpenBSD is because of paid shills like you. Which is a shame, because FreeBSD is a much more stable, well documented system.
My Question for you, Mr. Raven is how do you get paid by the FSF to make these comments when your whole damn operating system is free!?
Of course, I'm joking about the paid shills (maybe) but I'm serious about linux (for all values of $DISTRO) being a shitty operating system. FreeBSD is far better. Vista is much better than them on, at least on the desktop.
Yup. You nailed it. Anybody who likes a Microsoft product is clearly a shill for Microsoft. I am clearly paid by Microsoft to make these comments. You got it. Sorry for the mistake.
Come to think of it, maybe you are the one getting paid by the Apple to post your comments. Why don't you go talk to *your* manager at apple and ask for a raise? Maybe you should quit your job at Apple and go work for RMS at the FSF. I hear they pay real great to shill the Hurd. I've heard he even flies first class when he makes trips to paris for uninvited visits to important officials. You damn shill... get back to making GNOME not suck or something...
It is even cooler when you see that even on this site there are more vista users than mac users.