It's WINEPREFIX. Same concept, though -- by default it's ~/.wine, but if I want it to go somewhere else, I can.
An example of practical use: I believe IEs4Wine does this, because Internet Explorer doesn't generally like having multiple versions on the same Windows. So it just creates multiple fake Windows installs, and switches between them with WINEPREFIX.
Cedega actually provides a GUI for this. You can install each game in its own "game folder", each of which is a fake Windows. Thus, no one game that runs on Cedega can possibly be incompatible with another game, or interfere with it in any way -- unless you want them to (obviously you can install multiple things onto the same "game folder", including patches and mods to a game you already have there).
That's part of the point. If a program uses $HOME instead of getpwent or whatever, that means I can have multiple config profiles for that program saved somewhere, assuming it doesn't support them by itself.
In fact, Wine supports this kind of thing explicitly, with the WINEHOME environment variable.
Now, why wouldn't you want to support stuff like this in an app like Skype?
He wanted to remove a formula from a given cell. His first attempt was to simply remove the formula and change the value.
Instead, he has to go update all the reference and dependency information, which programs have to generate and update all the time anyway. I can't really think of a good reason this information needs to be saved to disk, and I certainly can't think of a good reason that Excel deletes the cell, rather than updating the dependencies itself to reflect the physical document.
In fact, I can't think of a good reason to store the value alongside the formula, except as an optional cache, which a program can recalculate if needed.
They are using XML in the first place. The point of XML is interoperability and human-readability/editability, not performance.
Back in 99 or 2000 or so, I could say, with a fair amount of confidence, that the word processor I used (I think it was AbiWord) was far superior to MS Word for that purpose. It was lightning-fast to open and run, had quite a lot of features Word didn't, was free (and a very small download), and often supported old Word formats better than Word itself.
But it wasn't completely compatible. It couldn't actually save a Word document, so it would save to RTF when people told it to, so they would stop getting requests for that functionality. And if you were to ever show anyone one single thing out of place when you imported their document, they wouldn't touch it with a 10 foot pole.
Now, I admit OpenOffice is huge and bloated, and in some ways is behind Word -- although it is ahead in other ways that I doubt you notice, since it sounds like you haven't given it a try. But we've learned our lesson.
The fact is, as long as there isn't a standard format, you cannot compete on merit. Linux was better than Windows in just about every way for a very long time. Windows XP started to make it less of an issue, and Vista finally implements Sudo properly, but Linux and OS X are still better than Windows in quite a lot of visible ways. But since there's no easy, standard way to write portable apps -- and Microsoft has actively tried to kill attempts like Java -- people use Windows because they have apps that need Windows because they use Windows.
Now, you're partly right -- Firefox is where it is because IE 6 sucked so much for so long that just about anything would be better. But it also exists because there was at least an attempt at a standard of HTML, JavaScript, CSS, and so on. If there had only been "Microsoft BinaryML", the Internet would have been Windows only.
Congratulations on including more profanity than actual content in your post...
Oh, here's a hint: "Hacking something up" involves, in Bash, simply accessing $HOME. In Perl, it's $ENV{HOME}. Even in C, it's something like getenv("HOME").
If that's your idea of "hacking something up", you've clearly never been a programmer. If you really think accessing the 8th element of the array returned by getpwent() is more readable than the above, you're also clearly retarded.
Or is it the lack of documentation? Bullshit. I just did a 'set | grep sanity' at the commandline, found I have HOME=/home/sanity. Took far less time than it'd take to Google for "Standard POSIX way to find the home directory without pissing off Anonymous Cowards."
Note also that I said "it could be innocent." I didn't even say that environment variables was a better or easier way. I just said that nobody has to read/etc/passwd to find the user's home directory, which is true.
It looks to me like he grew up in... didn't say any faith, except "liberal", which could count, I guess.
He then tried radical Islam, then Christianity.
So that's two, at most three. Hardly "wandering aimlessly... trying each on like a new shirt."
I'd actually have a bit more respect for him if he'd at least considered a few more -- then he'd be making an informed decision, at least as much as you can about religion. As it is, I'm betting he was raised Christian, tried Islam, then defaulted back to Christianity when Islam didn't work.
I'm coming a little late to this discussion, and I'm afraid I'll be lost in all the "too many distros" and "my wifi card doesn't work" spam. But I do have a few ambitious ideas that no one else seems to have mentioned...
First, stop writing stuff in C.
Recently, I copied all of my important stuff onto another hard drive and then back, and lost most of it, due to a buffer overflow in cpio. I should have had backups, but then again, if I'd done backups the way I archived stuff there, I could have run into the same problem, where my backups would all be corrupt, and I wouldn't know it until I went to check.
So, my first project would be to figure out what language to use, and develop it to where it's production-ready, and supports enough low-level stuff that we can write most of the kernel in it. If no such language exists, I'd write a new one. So many languages are close -- lately I like Python, Perl6, and JavaScript -- but none of them are anywhere near being a complete win over C, even for applications. The best-looking ones are also entirely too weird -- Haskell, Erlang, and so on.
With the right language/environment, I wouldn't even be afraid of running everything in ring 0, except for legacy code. I realize why this is usually considered a bad idea, and I have a solution, but I'm trying to keep this post short...
This would involve completely rewriting the kernel eventually, but it wouldn't have to be done all at once.
Filesystems are another area of interest. I would rather get the "kernel rewrite" above at least started before tackling this one, though. Right now, the choices are: Write your FS in the kernel for speed, or write it in FUSE for flexibility. I'd rather just write it wherever (since kernel/userspace would have no meaning in the above "kernel"), and have it perform well and be able to do everything I want.
There are some good starts here -- both KDE and Gnome have a VFS layer in userspace. Apps use URLs to access everything -- files are in the "file:/" hierarchy, but there are others. For example, in KDE, I can type: "fish://user@host/some/where", and it will use SSH to access those files.
But the problem with these approaches is that they aren't supported by legacy apps. Sure, you can wrap them in FUSE, but then you take a large performance hit.
The other problem is that there's the GNOME VFS and the KDE VFS, and as far as I know, they don't cooperate. That's my rationale for doing it at the "kernel" layer -- every app would be forced to use one API, or have no access to the filesystem. You could still have competing implementations, but at least you don't have to worry about supporting one or the other in your app anymore.
The filesystem API itself is problematic, too. Right now, there's no reasonable way to do well-performing transactions, without practically implementing a filesystem on top of the filesystem. This is what both MySQL and PostgreSQL do, by the way -- they just throw everything together into one file, and implement their own journaling. You may have noticed that there are tons of filesystems for Linux, and they all suck -- this is one reason why. I don't believe write barriers are enough.
I know about ZFS. For some reason, whenever I mention these obvious problems with the POSIX filesystem API, people point to ZFS as if it magically solves all filesystem issues.
All ZFS demonstrates is that the Linux kernel's filesystem API is deficient, that the layers we've chosen simply will not work. Redundancy, multi-device support, multiple machines, bad block relocation, cryptography, compresson, indexing, and relationships are all things I think a "filesystem" should have to deal with. Right now, here are the solutions I know about:
- RAID will do redundancy locally. DRBD will do a very simple RAID-1 over several machines. They obviously don't share code, or DRBD would be able to do RAID-5, for example. And they operate at the block level -- good, because you can run any filesystem on them, but bad
Funny, that's kinda black and white there, isn't it? Are you really implying that 1 ripped copy = 0 lost sales?
No, I'm not, although I would suggest that's most often the case.
After all, no one here is claiming that 1 ripped copy = 1 lost sale. Only corporate shills do that.
They do it often enough that I have to keep bringing up this argument, again and again.
Look at my wording again: A pirated copy is not a lost sale. It's almost never possible to take an instance of piracy and map it directly to one lost sale.
Maybe I need better wording, but what I am trying to say here is precisely that it's not black and white, that you can't look at any loss of sales and map it directly to piracy, or vice versa. Partly because of that, most forms of copy protection really need to be looked at in much more depth than simply "they would pirate if we didn't," because that's simply not true -- sometimes, they pirate because of the copy protection.
You give an example of a text file, that's easy to understand, and is four lines long. You then suggest literally five times as much XML, just to describe what's a valid value in the text file?
Alright, first of all, "connectionsMax" doesn't need to be validated for anything other than being a number. The actual implementation may have a limitation like you suggest, but I don't really see a reason for it to, except maybe theoretical OS limitations like maximum number of threads running at a time. It seems you agree, because you suggest 0 as a min -- in config files, setting a max of 0 usually means "unlimited", because presumably this is a config file for something which needs at least one connection.
Limiting SSL to boolean, I can see. I can even see doing validation -- certain things, like visudo, already do validation on save, and other things, like Postfix, do validation right before a restart, so that Postfix will keep running with the old configuration if the new one is invalid. Most things can deal with invalid lines in their config files anyway.
I don't necessarily disagree with the features you want, the XML just seems superfluous to me. And your "export/import" works fine for those who like vi/emacs/nano/whatever -- just check out visudo, vipw, vigr, etc for an example of how it's done. But it doesn't work so well for a graphical editor, where people could have more than one file open at once, not want to close it just to save, etc.
Also, you do underestimate text files. There's plenty of room in there to throw a lot of comments (including your "short" and "long" examples), they're as "user friendly" as anything else if you can find them -- or maybe I just don't know any users who find it easier to click a checkbox than to type "true" -- and they are actually much easier to navigate (using a search) than a GUI representation of them would be, unless you did a lot more work on that GUI than your XML example.
In fact, it's only recently that GUI configurations became searchable, and it's still not very good, compared to what I can do with a text file.
The downside is, you don't always know which text file to edit, or how to get to it. Also, text files are slow, for anything more than simple configuration. But that's about it.
How does one make the connection from "this app is written in Python" to "I need a package whose name is Trac"?
Because the name of the app is Trac. That was just an example -- the old, open source BitTorrent is written in Python, so you would follow the same instructions, only for BitTorrent instead of Trac.
The connection is "I need an app named Foo", so you then go to Synaptic (or Adept, or aptitude, or apt-get) and find Foo, and say "Install Foo". You don't even have to know if the app is written in Python or not -- Python will be installed for you if it's needed.
Compare this to trying to install a Python app on Windows. The only reason things are as easy as they are on Windows is that they will wrap both the Python app and Python itself into one installer, and each app will have its own version of Python, wasting disk space and RAM.
Trouble is that not enough developers have the time to package their apps for every distribution under the sun. This puts us back to the "this OS has too few apps; I'm sticking with Windows XP because I can more easily find apps that are packaged for it" complaint.
It actually doesn't take that much work.
You will only really have to make three packages, at most: A source tarball, a Debian package, and an RPM.
The source tarball means that anyone who knows about make and has time to waste can install it on any distro, or build their own package. It's also close to no work for you, since you probably already have everything you need in a directory somewhere -- you just have to tar it up.
The Debian package will probably work on both Debian and Ubuntu, and also oddballs like Linspire. Bonus points if you want to host your own repository, like certain projects do -- it probably isn't much more difficult. It might also be included in one of the mainstream repositories, but even with no repository, end-users know how to download and double-click on stuff, and it does work to download a.deb and double-click on it in a GUI.
All of the above is pretty much the same for the RPM -- it'll work on RedHat Enterprise Linux, CentOS, Fedora, and even oddballs like Mandriva, it may be included in a mainstream repository, but worst case, people can download and double-click on it.
That's really it. Distros are similar enough these days that if you provide these three forms, you've covered probably 99% of Linux users. The other 1% will be people on really strange distros like Slackware and Gentoo, and if they're using a distro like that, chances are they know how to use your source tarball -- in the case of Gentoo, chances are they made a "package" before you even knew that Gentoo existed.
I've always been able to resize Windows partitions with no problems, but I use commandline tools like ntfsresize. Maybe the installer uses something else?
I do know that it does have to defragment a bit -- it does move files out of the way in order to shrink the partition.
Christians are taught to forgive. Muslims are taught to die in defense of Islaam.
Wrong.
Both are supposedly taught to forgive. It only took me about a minute on Wikiquote:
Satan threatens you with the prospect of poverty and bids you to be niggardly, whereas God promises you His forgiveness and bountyIf you do deeds of charity openly, it is well; but if you bestow it upon the needy in secret, it will be even better for you, and it will atone for some of your bad deeds
That's from the Qur'an. Looks like it's not only preaching forgiveness, not only charity, but secret charity, because if your charity was public, you might be doing it out of vanity.
And let's not forget -- Islam does accept Jesus as a prophet.
But both sides are also perfectly willing to pervert their belief until it's unrecognizable. Think of the Crusades, of Nazi Germany, of any of the things Christianity has done in the name of God...
But I'll tell you what -- God isn't happy with any of us. But here's the trick: That article is about all of us, not just people you disagree with.
/etc/passwd needs to be read for almost any trivial thing to be accomplished, such as finding out your home-directory so that.skype can be read, or for displaying ownership of files in a file-dialog.
Actually, both of those examples can be much more easily discovered with common environment variables. USER shows my username, LOGNAME seems to be another variant of that, HOME is my home directory, and so on.
Now, I admit that they might have just decided to use standard library functions to find that out, and those standard library functions read passwd, so it could be innocent. But your assertion is blatantly false.
Now, as to why skype needs to read firefox configuration files, I have no idea.
Your suggestion about "integration" doesn't make a lot of sense, because I don't believe it does connect to Firefox in any way. If we checked in more detail, we could probably figure out if they're trying to read your web passwords and such.
But considering that Skype on Windows reads your BIOS, and that Skype is made by the same people who put spyware in Kazaa, I don't think it's unreasonable to assume the worst.
SIP, if I remember, requires so many open ports you may as well not try unless you're sitting on a real Internet IP address, with no firewall, at both ends.
I believe there's something else you can use instead, some Asterisk-specific but somewhat widely-supported protocol, a bit simpler, only requires one port. There's also Jabber/Gtalk -- I know Kopete supports that now, among other clients. I don't know exactly how the voice works, but it is nice to be able to have one or more central servers to connect to, so at least your endpoints can be behind whatever firewall/NAT people have set up.
But Skype is actually the technically best solution I've seen, and I wish there was an open source alternative, or an open spec. It actually uses some UDP tricks to allow you to open a connection directly between the two endpoints, requiring no bandwidth from Skype, even if both endpoints are firewalled and NAT'ed. It does require at least one publicly-accessible server, but only for the initialization.
Of course, for conferences, I'd have to recommend mumble, which looks to be intending to replace TeamSpeak and Ventrillo for voice chat in games.
Calm down and get some real evidence of wrongdoing like a packet capture of private information going out over the wire before you cry wolf.
Well, the private information going out over the wire is kind of encrypted...
But think about the big picture. Aren't the guys making Skype the same guys that put the malware in Kazaa? It's the opposite of crying wolf -- when you say "I'm innocent!" for long enough when it's not true, no one will believe you're innocent even when you are.
People wonder why we don't trust anything Microsoft does? Same thing, only moreso.
It's not like the evil code is necessairily going to be in a function called doEvil(), it could be very cleverly hidden among legit functions so that most people would miss it.
The more obfuscated it is, the more likely it is that the open source community would just rewrite that chunk of code for being too difficult to understand.
The challenge is not only to make it impossible to see what the code is doing, but to make it possible to think you know what the code is doing, and still miss what it's really doing. And at the end of the day, it has to spell out/etc/passwd in the code somewhere, or it has to have code that generates it, and it would take a LOT of work to write code which generates '/etc/passwd' while also never spelling it and looks innocent.
(Ditto for any other way you'd do this. There are standard library functions to access passwd, and those would be just as hard to hide.)
Second, you assume the people who look at it aren't in on it. So maybe a couple people look at the code and find the evil bits. They contact the developer and ask what's up. The developer then lets them in to his cabal, who can use the evil bits for their own ends. The people decide they like this and don't tell anyone.
You only need one whistleblower developer to end that charade. And that one whistleblower would bring in hundreds or thousands of developers who'd never bothered to look at the code, who would read it and say "Yep. Looks evil."
Compare that to proprietary software -- it takes someone actively trying to reverse-engineer the software in some way; here, running it in a restricted environment. Even once you have someone doing that, it can be a lot less trivial than "just look at the source" for someone else to verify it.
Third you assume that anyone other than the developer even bothers to look at the code. Not always a valid assumption, just because the code if you there doesn't mean anyone gives a shit. Maybe it is too complicated, maybe they just don't care, regardless the code being open is no guarantee that someone looked.
Well, this is Skype we're talking about. It's popular enough that someone would have looked.
Also, consider the person making such "evil" software -- would they really be ballsy enough to assume no one would read the source? True, there could be some open projects with "evil" code in them that nobody's bothered to read, but anyone doing that is taking the chance that someone, somewhere, would read it and discover what they're doing.
And then there's the question of what happens when they discover it. Like right now, no one has a clue why Skype would be reading passwd. We assume it's evil, but we don't really know. Were it open source, we could just go read the code, and instantly see if there's a legitimate reason. If there wasn't, we could patch the "evil" bits out and keep using Skype as if nothing happened.
Fourth, you assume that the binaries are the same as the source. I'm betting at least some of the time, and probably more often than that, you install things from a binary package. It's easy and much faster than compiling everything. Great, but how do you know the source follows the binaries? It would be easy to release an untainted source, and then tainted binaries.
As the sibling post says, in general, most distros compile from source. So if you trust Ubuntu, say, you don't have to trust a hypothetically open source Skype in this respect -- the Ubuntu people would have compiled it from source themselves, and cryptographically signed the binaries.
Some other program, and not just the compiler, could be in on inserting a trojan. It might never exist in source form, yet always get compiled in. Thus even a build from a verified source isn't a defense.
That kind of rules out it being Skype's fault, then, for
As far as I'm concerned, 2K Games has destroyed its credibility, and they can go to hell for it.
The thing is, you can't both have that attitude and be a gamer, unless you intend to only play old GPL'd games. Just about all modern games do this kind of stuff -- even, if I remember, things like Doom 3 on Windows, even though there's a native Linux version with basically no copy protection.
The way I operate here is, I will buy any game which is worth playing, and has copy protection that I can either crack or live with. I will also prefer games which I can make work on Linux, even if it requires Wine/Cedega.
Kind of like how I will buy or rent DVDs, but not HD-DVD or Blu-Ray, because DVDs are cracked enough at this point that they may as well not have copy protection, but HD-DVD and Blu-Ray are still protected enough that I can't play them easily on Linux with mplayer.
Basically, I figure the main reason I don't like copy protection is that it forces me to have a physical copy and to run on Windows, using mostly proprietary software, and could potentially cause security issues. Games generally force me to run Windows and proprietary software anyway, so the only real cause I have for concern about issues like this is whether I can play without the CD and whether I can prevent the rootkit from getting as deep into my system as it wants.
Now, in the case of Bioshock, it may or may not change in the future. Often, the developers don't like rootkits any more than we do, and it's something the publishers force on them. Future patches have removed this kind of thing before. If that happens, I'd definitely consider purchasing it. However, I'd also consider purchasing it as soon as I'm sure there's a decent crack for it...
It's just a little hard to "vote with your dollars" when there's not really much alternative, other than maybe going to a completely locked down system, like a game console.
Expecting to be paid for your software is reasonable.
Taking tactics which can actually damage your customers' computers is not.
In fact, copy protection is entirely unnecessary to be paid for your work. Just look at record sales -- people do, in fact, still buy CDs, even though most have no copy protection at all. They even buy DVDs, even though the protection there has been so thoroughly cracked that there are one-click programs to rip a DVD and put it on your video iPod. Plenty of people still subscribe to Cable TV, even though most shows are available within a few hours on BitTorrent.
Oh, and by the way, before you mention it -- a pirated copy is not a lost sale. A pirated copy is not a lost sale. A pirated copy is not a lost sale. Repeat this until you understand it, and then take another look at the statistics -- the RIAA/MPAA are still insanely rich, as are the better artists, musicians, directors, and so on. There is simply not significant evidence, anywhere, that they have lost money due to piracy.
I know it's comforting when you can believe the world is black and white, but it isn't.
Look, I realize this is a sad situation, and some people are starving, but...
I reserve the right to laugh at hilarious situations, even -- especially -- when they are a matter of life and death.
Take the kid who played videogames for some 3 days straight, no breaks at all, till he actually died -- yeah, it sucks to have someone die, and if I'd known the guy, I'd be sad. But it's still funny as hell.
There's no business case there. No customer would willingly pay to upgrade, pay more for the ISP to upgrade their bandwidth and get... a more limited and failure-prone system than they have now.
I don't think it has to be much more limited. And right now, most customers have nothing or BitTorrent, and BitTorrent is soon going to be impractical for them.
I think the other question is reliability. Multicasting is inherently failure prone - as it depends on a very reliable network to reach all customers in near real-time.
Do UDP. Customers which don't get a particular chunk can ask for it again, as they continue to download the rest. If everyone has really, really unreliable networks, and if you're not doing any caching, then it would start to cause problems with your ISP's uplink. Other than that, I think it would work well.
Multicasting requires a "broadcast" of packets - providing an easy target of attack.
Sign the packets and they can only DoS you. And I'm hoping you're not suggesting DRM-ing them, as the whole point of this exercise is the assumption that customers will pay for better service.
having owned an Alienware for many years is what got me in the game of geekdom.
Hmm... Could you explain how that works?
Specifically -- what about that Alienware made you more likely to be geeky than any other PC?
Or is it that you resent me calling you a "Geek Wannabe", even if you now realize how dumb an Alienware purchase is? I'll admit people can grow and change, but whenever you bought that Alienware, you were either a Geek Wannabe of some sort, or a complete moron with your money.
Beside you overlook the fact that many software geeks are not necessarily inclined to be hardware geeks and visa versa.
Maybe not, but it's a simple matter of economics. I'm not generally a hardware geek either, but I do my homework when I make just about any purchase, or I talk to someone who has. It is absolutely worth my time to do the research, and even assemble a machine myself if need be, when the price difference is $1000 or so for an otherwise identical machine.
This applies to other kinds of geeks as well. If I pick up Top Ramen at, what, $2 for a 12-pack, cook it, and serve it to you in an oriental-looking bowl, branded "Naruto Ramen," and charge you $50 for it, well, you got ripped off. If I take a $150 air conditioner, slap a sticker of an alien on it, and sell it to you as an "Alienware cooling system" for $500, guess what? You got ripped off.
Now, maybe you've actually reached the point where you make so much money that the time spent comparison-shopping is actually worth more than the thousand dollars or so you lose by going with Alienware. Or maybe I'm out of it and Alienware is actually charging reasonable prices now. Neither seems likely.
I am not normally so reflexively insulting. I'm a rabid Linux zealot, but if you have to use Windows, I can understand. I'm even more rabidly anti-DRM, but I can understand just wanting to plug in your shiny new Xbox 360 and not think about it. But I honestly cannot think of a good reason for buying an Alienware, other than, say, extreme inebriation.
but not so geeky as to remain a virgin well into my 30s
What does that have to do with the current discussion?
For that matter... Are you married? Do you think your wife would consider Alienware a good decision? A thousand dollars for a pretty-looking case, and better-looking and cheaper ones on Newegg for less than $50?
Wait, hold that thought. I have some ch34p r0l3x and v1agr4 to sell you.
Not a huge one, but it is an issue when you consider that you may eventually want to convert your archive to another format, or display it in another format.
That's easy in documents designed to be edited. It's easy to, for example, convert odf to html, or pdf, or plain text. It's much harder to convert pdf to one of these other formats -- I've tried a PDF to text conversion, and a PDF to html conversion, and neither worked the way I wanted.
I can, and have, shown it to be spyware, by one of those links. You know this -- that it sends out statistical information, and that it does so without your knowledge or consent.
What more do I need, a big sign on it that says "WARNING! VIRUS.EXE!!!"
Oh, I dunno about that, but... given July 2007 data, right here, in the url below?
I see "vulnerabilities fixed". Nothing about how many were actually exploited.
Saying "this many vulnerabilities were fixed" is an even less relevant metric than "this many machines were exploited", because fixing a vulnerability is a good thing. How many vulnerabilities are still out there for Windows, unpatched, maybe undiscovered? Doesn't it make sense that Linux, with its source available, would be easier to find vulnerabilities in (and fix them)?
HOWEVER, the EXECUTABLE FILES page back, to their backing file on disk (their.exe named one).
Right. This is actually intelligent, as you say, because it doesn't have to write anything to "page out".
In fact, this would more accurately not be called "paging" so much as having stuff expire from a cache.
In any case, I do think that having a pagefile (or swap space) makes sense, if the kernel is at least sometimes more likely to swap something out than to expire something (executable or not) from the cache. But I don't see the value of putting it in RAM -- the whole point of a pagefile is to provide more storage for when you're low on RAM, or to let the OS use the RAM for something else.
Well, I like 1 thing about using.ini files (windows' state keeping files for apps in the old days, & currently): 1 grenade does not take out the WHOLE PLATOON... but, they're.txt text files, so their access is slower than registry binary storage.
Linux apps tend to use text configuration files for configuration. Storage is in whatever format they want, usually binary (more like.dat), but configuration doesn't need to be fast.
For example: My Postfix server has a configuration split across several files, some of which I've edited, some of which I deliberately have not. It reads them when it starts up, which is basically once per Postfix update or kernel update, and it reads them when I make a change. It then stores its configuration in RAM.
(Postfix, by the way, is an example of how to design a Unix app securely. It's split into many small cooperating processes, many of which are run in a chroot which cannot be broken out of, because the app is not running as root, and there are no executable files in there -- meaning your method doesn't work.)
Adobe Photoshop users usually, but, it makes some sense: They CAN work in some pretty LARGE data, in photography oriented data, @ least @ times & by NOT using a pagefile with that app? You had best be working with 'smaller' data (purely relative term, hence the sarcasm quotes).
Well, first of all, on a machine with 8-16 gigs of RAM, I doubt the Photoshop guys are going to have any trouble. I'm actually fairly sure the Windows pagefile has a size limit anyway, by default.
But that's the point -- You were advocating putting the pagefile on a ramdisk, which makes absolutely NO difference for the Photoshop guys. In fact, it may even slow them down, versus not having a pagefile.
Lack of a pagefile.sys might 'upset' that cpu mgt./memmgt. they use
Well, like I said, if they have that much knowledge and control over virtual memory, I see that as a design flaw. Processor affinity and thread priority is one thing, but the only place I see a point to an app knowing about swap is for it to explicitly mark a particular page as RAM-only, due to it containing sensitive information that shouldn't touch disk unencrypted.
I may be missing something, but I just can't think of another place where it's a good idea for an app to know about the OS pagefile (or swapspace). Can you?
Well, I can do that, right now, in Windows: IMMEDIATE REGISTRY WRITES
I know. Every OS has some form of sync. I'm just saying that if transactions are implemented as I suggest, I don't want to lose that feature.
Note: I already do that - search where I said about cmd.exe & COMSPEC via environmental %variables% alterations... I put my command interpreter there.
Good. So...
What I would recommend is making the ramdisk as small as possible (but no smaller), and turning off the pagefile if you can, otherwise sticking it on the ramdisk and turning the size limit way down on it.
I thought I'd get rid of this stuff first, so I can get on to the filesystem stuff. And please don't just reply to random posts of mine, completely offtopic like that -- I wasn't ignoring you, I simply didn't have a functioning machine for awhile (hardware).
1.) This tool might be malware - I can only say, PROVE THEN THAT IT IS!
Burden's on you to prove that it isn't.
If it is malware, and I download it, then my system is compromised, and/or I have to spend a lot of time setting up a sandbox for it.
If it's not malware, and I refuse to download it out of paranoia, there's no huge loss to me. Certainly nothing on the order of what I might have lost, were it malware.
2.) This program may send data out I am not aware of - but, you are (they record data for security purposes
Right, but they never made that clear, which means they never particularly cared whether I'd know about it or not.
Also, I'm pointing to this as a way of questioning their credibility, same as the security hole in their own software. I'm not going to trust security testing software (or its results) from an organization that can't secure their own software and intends to collect data without my knowledge or consent.
I know about this from the other articles you linked to. CIS said nothing about it themselves.
3. That SeLinux know-how on your end is not needed - & you refuse to learn its "intricacies" as you put it...
It's not needed on my end, except for running untrusted software like you've suggested. So, I'd rather not learn it unless I have a good reason to.
Well, I proved that even IF you run an app as Non-root/non-superuser/non-administrator? An app with a buffer overflow vulnerability present in it can ESCAPE even chroot jails (the SINGLE layer of security you used, omitting chown/chmod + SeLinux layered security ontop of those, via MAC)...
Well, I did use chown/chmod, as well as su/sudo. So, saying I used a "SINGLE" layer of security is deceptive at best.
You're very good at sensationalist writing, and that has a place and a time -- advertising, maybe. But it has no place in a technical discussion.
What's more, you're innaccurate here. You can put all the buffer overflow vulnerabilities you want in an app which runs as non-root, and it still won't be able to gain root or escape the chroot jail.
What that app needs is a buffer overflow vulnerability in the kernel itself, or in an app which runs as setuserid root. About that, you're right, but the way you've phrased it, I wonder if you really understand what you're saying.
You're also missing the "not worth my time" argument, especially true this weekend... which was when I was planning to do this, but deadlines and more deadlines, not having a computer kind of delayed that project...
Still, it's NOT Windows, on many fronts (inclusive of security, because until somebody can show me, in a valid unfaked photo here per my challenge, a screenshot of a *NIX person exceeding my score on a VALID test of security based on "best practices" for the OS platform on which it's run in CIS TOOL? I am NOT convinced that LINUX is the way to go, & certainly NOT for security!)...
Try it yourself.
No, really. If you're half as paranoid about security as you should be, you won't trust any photo anyone posts here. The only way you'll get a score you can trust is to run the tool yourself. For all I care, get an install CD in the mail and run it within the live environment...
But here's the point I seem to be having difficulty communicating with you: Neither this test, nor any test like it, can really test cross-platform. Suppose for a moment that Linux didn't support ACLs -- in that event, any reasonable cross-platform security test would omit a check of ACLs being enabled on Linux.
Slashdot Mirror
It's WINEPREFIX. Same concept, though -- by default it's ~/.wine, but if I want it to go somewhere else, I can.
An example of practical use: I believe IEs4Wine does this, because Internet Explorer doesn't generally like having multiple versions on the same Windows. So it just creates multiple fake Windows installs, and switches between them with WINEPREFIX.
Cedega actually provides a GUI for this. You can install each game in its own "game folder", each of which is a fake Windows. Thus, no one game that runs on Cedega can possibly be incompatible with another game, or interfere with it in any way -- unless you want them to (obviously you can install multiple things onto the same "game folder", including patches and mods to a game you already have there).
That's part of the point. If a program uses $HOME instead of getpwent or whatever, that means I can have multiple config profiles for that program saved somewhere, assuming it doesn't support them by itself.
In fact, Wine supports this kind of thing explicitly, with the WINEHOME environment variable.
Now, why wouldn't you want to support stuff like this in an app like Skype?
He wanted to remove a formula from a given cell. His first attempt was to simply remove the formula and change the value.
Instead, he has to go update all the reference and dependency information, which programs have to generate and update all the time anyway. I can't really think of a good reason this information needs to be saved to disk, and I certainly can't think of a good reason that Excel deletes the cell, rather than updating the dependencies itself to reflect the physical document.
In fact, I can't think of a good reason to store the value alongside the formula, except as an optional cache, which a program can recalculate if needed.
They are using XML in the first place. The point of XML is interoperability and human-readability/editability, not performance.
Back in 99 or 2000 or so, I could say, with a fair amount of confidence, that the word processor I used (I think it was AbiWord) was far superior to MS Word for that purpose. It was lightning-fast to open and run, had quite a lot of features Word didn't, was free (and a very small download), and often supported old Word formats better than Word itself.
But it wasn't completely compatible. It couldn't actually save a Word document, so it would save to RTF when people told it to, so they would stop getting requests for that functionality. And if you were to ever show anyone one single thing out of place when you imported their document, they wouldn't touch it with a 10 foot pole.
Now, I admit OpenOffice is huge and bloated, and in some ways is behind Word -- although it is ahead in other ways that I doubt you notice, since it sounds like you haven't given it a try. But we've learned our lesson.
The fact is, as long as there isn't a standard format, you cannot compete on merit. Linux was better than Windows in just about every way for a very long time. Windows XP started to make it less of an issue, and Vista finally implements Sudo properly, but Linux and OS X are still better than Windows in quite a lot of visible ways. But since there's no easy, standard way to write portable apps -- and Microsoft has actively tried to kill attempts like Java -- people use Windows because they have apps that need Windows because they use Windows.
Now, you're partly right -- Firefox is where it is because IE 6 sucked so much for so long that just about anything would be better. But it also exists because there was at least an attempt at a standard of HTML, JavaScript, CSS, and so on. If there had only been "Microsoft BinaryML", the Internet would have been Windows only.
Congratulations on including more profanity than actual content in your post...
/etc/passwd to find the user's home directory, which is true.
Oh, here's a hint: "Hacking something up" involves, in Bash, simply accessing $HOME. In Perl, it's $ENV{HOME}. Even in C, it's something like getenv("HOME").
If that's your idea of "hacking something up", you've clearly never been a programmer. If you really think accessing the 8th element of the array returned by getpwent() is more readable than the above, you're also clearly retarded.
Or is it the lack of documentation? Bullshit. I just did a 'set | grep sanity' at the commandline, found I have HOME=/home/sanity. Took far less time than it'd take to Google for "Standard POSIX way to find the home directory without pissing off Anonymous Cowards."
Note also that I said "it could be innocent." I didn't even say that environment variables was a better or easier way. I just said that nobody has to read
It looks to me like he grew up in... didn't say any faith, except "liberal", which could count, I guess.
He then tried radical Islam, then Christianity.
So that's two, at most three. Hardly "wandering aimlessly... trying each on like a new shirt."
I'd actually have a bit more respect for him if he'd at least considered a few more -- then he'd be making an informed decision, at least as much as you can about religion. As it is, I'm betting he was raised Christian, tried Islam, then defaulted back to Christianity when Islam didn't work.
I'm coming a little late to this discussion, and I'm afraid I'll be lost in all the "too many distros" and "my wifi card doesn't work" spam. But I do have a few ambitious ideas that no one else seems to have mentioned...
First, stop writing stuff in C.
Recently, I copied all of my important stuff onto another hard drive and then back, and lost most of it, due to a buffer overflow in cpio. I should have had backups, but then again, if I'd done backups the way I archived stuff there, I could have run into the same problem, where my backups would all be corrupt, and I wouldn't know it until I went to check.
So, my first project would be to figure out what language to use, and develop it to where it's production-ready, and supports enough low-level stuff that we can write most of the kernel in it. If no such language exists, I'd write a new one. So many languages are close -- lately I like Python, Perl6, and JavaScript -- but none of them are anywhere near being a complete win over C, even for applications. The best-looking ones are also entirely too weird -- Haskell, Erlang, and so on.
With the right language/environment, I wouldn't even be afraid of running everything in ring 0, except for legacy code. I realize why this is usually considered a bad idea, and I have a solution, but I'm trying to keep this post short...
This would involve completely rewriting the kernel eventually, but it wouldn't have to be done all at once.
Filesystems are another area of interest. I would rather get the "kernel rewrite" above at least started before tackling this one, though. Right now, the choices are: Write your FS in the kernel for speed, or write it in FUSE for flexibility. I'd rather just write it wherever (since kernel/userspace would have no meaning in the above "kernel"), and have it perform well and be able to do everything I want.
There are some good starts here -- both KDE and Gnome have a VFS layer in userspace. Apps use URLs to access everything -- files are in the "file:/" hierarchy, but there are others. For example, in KDE, I can type: "fish://user@host/some/where", and it will use SSH to access those files.
But the problem with these approaches is that they aren't supported by legacy apps. Sure, you can wrap them in FUSE, but then you take a large performance hit.
The other problem is that there's the GNOME VFS and the KDE VFS, and as far as I know, they don't cooperate. That's my rationale for doing it at the "kernel" layer -- every app would be forced to use one API, or have no access to the filesystem. You could still have competing implementations, but at least you don't have to worry about supporting one or the other in your app anymore.
The filesystem API itself is problematic, too. Right now, there's no reasonable way to do well-performing transactions, without practically implementing a filesystem on top of the filesystem. This is what both MySQL and PostgreSQL do, by the way -- they just throw everything together into one file, and implement their own journaling. You may have noticed that there are tons of filesystems for Linux, and they all suck -- this is one reason why. I don't believe write barriers are enough.
I know about ZFS. For some reason, whenever I mention these obvious problems with the POSIX filesystem API, people point to ZFS as if it magically solves all filesystem issues.
All ZFS demonstrates is that the Linux kernel's filesystem API is deficient, that the layers we've chosen simply will not work. Redundancy, multi-device support, multiple machines, bad block relocation, cryptography, compresson, indexing, and relationships are all things I think a "filesystem" should have to deal with. Right now, here are the solutions I know about:
- RAID will do redundancy locally. DRBD will do a very simple RAID-1 over several machines. They obviously don't share code, or DRBD would be able to do RAID-5, for example. And they operate at the block level -- good, because you can run any filesystem on them, but bad
No, I'm not, although I would suggest that's most often the case.
They do it often enough that I have to keep bringing up this argument, again and again.
Look at my wording again: A pirated copy is not a lost sale. It's almost never possible to take an instance of piracy and map it directly to one lost sale.
Maybe I need better wording, but what I am trying to say here is precisely that it's not black and white, that you can't look at any loss of sales and map it directly to piracy, or vice versa. Partly because of that, most forms of copy protection really need to be looked at in much more depth than simply "they would pirate if we didn't," because that's simply not true -- sometimes, they pirate because of the copy protection.
You give an example of a text file, that's easy to understand, and is four lines long. You then suggest literally five times as much XML, just to describe what's a valid value in the text file?
Alright, first of all, "connectionsMax" doesn't need to be validated for anything other than being a number. The actual implementation may have a limitation like you suggest, but I don't really see a reason for it to, except maybe theoretical OS limitations like maximum number of threads running at a time. It seems you agree, because you suggest 0 as a min -- in config files, setting a max of 0 usually means "unlimited", because presumably this is a config file for something which needs at least one connection.
Limiting SSL to boolean, I can see. I can even see doing validation -- certain things, like visudo, already do validation on save, and other things, like Postfix, do validation right before a restart, so that Postfix will keep running with the old configuration if the new one is invalid. Most things can deal with invalid lines in their config files anyway.
I don't necessarily disagree with the features you want, the XML just seems superfluous to me. And your "export/import" works fine for those who like vi/emacs/nano/whatever -- just check out visudo, vipw, vigr, etc for an example of how it's done. But it doesn't work so well for a graphical editor, where people could have more than one file open at once, not want to close it just to save, etc.
Also, you do underestimate text files. There's plenty of room in there to throw a lot of comments (including your "short" and "long" examples), they're as "user friendly" as anything else if you can find them -- or maybe I just don't know any users who find it easier to click a checkbox than to type "true" -- and they are actually much easier to navigate (using a search) than a GUI representation of them would be, unless you did a lot more work on that GUI than your XML example.
In fact, it's only recently that GUI configurations became searchable, and it's still not very good, compared to what I can do with a text file.
The downside is, you don't always know which text file to edit, or how to get to it. Also, text files are slow, for anything more than simple configuration. But that's about it.
Because the name of the app is Trac. That was just an example -- the old, open source BitTorrent is written in Python, so you would follow the same instructions, only for BitTorrent instead of Trac.
The connection is "I need an app named Foo", so you then go to Synaptic (or Adept, or aptitude, or apt-get) and find Foo, and say "Install Foo". You don't even have to know if the app is written in Python or not -- Python will be installed for you if it's needed.
Compare this to trying to install a Python app on Windows. The only reason things are as easy as they are on Windows is that they will wrap both the Python app and Python itself into one installer, and each app will have its own version of Python, wasting disk space and RAM.
It actually doesn't take that much work.
You will only really have to make three packages, at most: A source tarball, a Debian package, and an RPM.
The source tarball means that anyone who knows about make and has time to waste can install it on any distro, or build their own package. It's also close to no work for you, since you probably already have everything you need in a directory somewhere -- you just have to tar it up.
The Debian package will probably work on both Debian and Ubuntu, and also oddballs like Linspire. Bonus points if you want to host your own repository, like certain projects do -- it probably isn't much more difficult. It might also be included in one of the mainstream repositories, but even with no repository, end-users know how to download and double-click on stuff, and it does work to download a .deb and double-click on it in a GUI.
All of the above is pretty much the same for the RPM -- it'll work on RedHat Enterprise Linux, CentOS, Fedora, and even oddballs like Mandriva, it may be included in a mainstream repository, but worst case, people can download and double-click on it.
That's really it. Distros are similar enough these days that if you provide these three forms, you've covered probably 99% of Linux users. The other 1% will be people on really strange distros like Slackware and Gentoo, and if they're using a distro like that, chances are they know how to use your source tarball -- in the case of Gentoo, chances are they made a "package" before you even knew that Gentoo existed.
I've always been able to resize Windows partitions with no problems, but I use commandline tools like ntfsresize. Maybe the installer uses something else?
I do know that it does have to defragment a bit -- it does move files out of the way in order to shrink the partition.
Wrong.
Both are supposedly taught to forgive. It only took me about a minute on Wikiquote:
That's from the Qur'an. Looks like it's not only preaching forgiveness, not only charity, but secret charity, because if your charity was public, you might be doing it out of vanity.
And let's not forget -- Islam does accept Jesus as a prophet.
But both sides are also perfectly willing to pervert their belief until it's unrecognizable. Think of the Crusades, of Nazi Germany, of any of the things Christianity has done in the name of God...
But I'll tell you what -- God isn't happy with any of us. But here's the trick: That article is about all of us, not just people you disagree with.
Actually, both of those examples can be much more easily discovered with common environment variables. USER shows my username, LOGNAME seems to be another variant of that, HOME is my home directory, and so on.
Now, I admit that they might have just decided to use standard library functions to find that out, and those standard library functions read passwd, so it could be innocent. But your assertion is blatantly false.
Your suggestion about "integration" doesn't make a lot of sense, because I don't believe it does connect to Firefox in any way. If we checked in more detail, we could probably figure out if they're trying to read your web passwords and such.
But considering that Skype on Windows reads your BIOS, and that Skype is made by the same people who put spyware in Kazaa, I don't think it's unreasonable to assume the worst.
SIP, if I remember, requires so many open ports you may as well not try unless you're sitting on a real Internet IP address, with no firewall, at both ends.
I believe there's something else you can use instead, some Asterisk-specific but somewhat widely-supported protocol, a bit simpler, only requires one port. There's also Jabber/Gtalk -- I know Kopete supports that now, among other clients. I don't know exactly how the voice works, but it is nice to be able to have one or more central servers to connect to, so at least your endpoints can be behind whatever firewall/NAT people have set up.
But Skype is actually the technically best solution I've seen, and I wish there was an open source alternative, or an open spec. It actually uses some UDP tricks to allow you to open a connection directly between the two endpoints, requiring no bandwidth from Skype, even if both endpoints are firewalled and NAT'ed. It does require at least one publicly-accessible server, but only for the initialization.
Of course, for conferences, I'd have to recommend mumble, which looks to be intending to replace TeamSpeak and Ventrillo for voice chat in games.
Well, the private information going out over the wire is kind of encrypted...
But think about the big picture. Aren't the guys making Skype the same guys that put the malware in Kazaa? It's the opposite of crying wolf -- when you say "I'm innocent!" for long enough when it's not true, no one will believe you're innocent even when you are.
People wonder why we don't trust anything Microsoft does? Same thing, only moreso.
The more obfuscated it is, the more likely it is that the open source community would just rewrite that chunk of code for being too difficult to understand.
The challenge is not only to make it impossible to see what the code is doing, but to make it possible to think you know what the code is doing, and still miss what it's really doing. And at the end of the day, it has to spell out /etc/passwd in the code somewhere, or it has to have code that generates it, and it would take a LOT of work to write code which generates '/etc/passwd' while also never spelling it and looks innocent.
(Ditto for any other way you'd do this. There are standard library functions to access passwd, and those would be just as hard to hide.)
You only need one whistleblower developer to end that charade. And that one whistleblower would bring in hundreds or thousands of developers who'd never bothered to look at the code, who would read it and say "Yep. Looks evil."
Compare that to proprietary software -- it takes someone actively trying to reverse-engineer the software in some way; here, running it in a restricted environment. Even once you have someone doing that, it can be a lot less trivial than "just look at the source" for someone else to verify it.
Well, this is Skype we're talking about. It's popular enough that someone would have looked.
Also, consider the person making such "evil" software -- would they really be ballsy enough to assume no one would read the source? True, there could be some open projects with "evil" code in them that nobody's bothered to read, but anyone doing that is taking the chance that someone, somewhere, would read it and discover what they're doing.
And then there's the question of what happens when they discover it. Like right now, no one has a clue why Skype would be reading passwd. We assume it's evil, but we don't really know. Were it open source, we could just go read the code, and instantly see if there's a legitimate reason. If there wasn't, we could patch the "evil" bits out and keep using Skype as if nothing happened.
As the sibling post says, in general, most distros compile from source. So if you trust Ubuntu, say, you don't have to trust a hypothetically open source Skype in this respect -- the Ubuntu people would have compiled it from source themselves, and cryptographically signed the binaries.
That kind of rules out it being Skype's fault, then, for
The thing is, you can't both have that attitude and be a gamer, unless you intend to only play old GPL'd games. Just about all modern games do this kind of stuff -- even, if I remember, things like Doom 3 on Windows, even though there's a native Linux version with basically no copy protection.
The way I operate here is, I will buy any game which is worth playing, and has copy protection that I can either crack or live with. I will also prefer games which I can make work on Linux, even if it requires Wine/Cedega.
Kind of like how I will buy or rent DVDs, but not HD-DVD or Blu-Ray, because DVDs are cracked enough at this point that they may as well not have copy protection, but HD-DVD and Blu-Ray are still protected enough that I can't play them easily on Linux with mplayer.
Basically, I figure the main reason I don't like copy protection is that it forces me to have a physical copy and to run on Windows, using mostly proprietary software, and could potentially cause security issues. Games generally force me to run Windows and proprietary software anyway, so the only real cause I have for concern about issues like this is whether I can play without the CD and whether I can prevent the rootkit from getting as deep into my system as it wants.
Now, in the case of Bioshock, it may or may not change in the future. Often, the developers don't like rootkits any more than we do, and it's something the publishers force on them. Future patches have removed this kind of thing before. If that happens, I'd definitely consider purchasing it. However, I'd also consider purchasing it as soon as I'm sure there's a decent crack for it...
It's just a little hard to "vote with your dollars" when there's not really much alternative, other than maybe going to a completely locked down system, like a game console.
Expecting to be paid for your software is reasonable.
Taking tactics which can actually damage your customers' computers is not.
In fact, copy protection is entirely unnecessary to be paid for your work. Just look at record sales -- people do, in fact, still buy CDs, even though most have no copy protection at all. They even buy DVDs, even though the protection there has been so thoroughly cracked that there are one-click programs to rip a DVD and put it on your video iPod. Plenty of people still subscribe to Cable TV, even though most shows are available within a few hours on BitTorrent.
Oh, and by the way, before you mention it -- a pirated copy is not a lost sale. A pirated copy is not a lost sale. A pirated copy is not a lost sale. Repeat this until you understand it, and then take another look at the statistics -- the RIAA/MPAA are still insanely rich, as are the better artists, musicians, directors, and so on. There is simply not significant evidence, anywhere, that they have lost money due to piracy.
I know it's comforting when you can believe the world is black and white, but it isn't.
Look, I realize this is a sad situation, and some people are starving, but...
I reserve the right to laugh at hilarious situations, even -- especially -- when they are a matter of life and death.
Take the kid who played videogames for some 3 days straight, no breaks at all, till he actually died -- yeah, it sucks to have someone die, and if I'd known the guy, I'd be sad. But it's still funny as hell.
I don't think it has to be much more limited. And right now, most customers have nothing or BitTorrent, and BitTorrent is soon going to be impractical for them.
Do UDP. Customers which don't get a particular chunk can ask for it again, as they continue to download the rest. If everyone has really, really unreliable networks, and if you're not doing any caching, then it would start to cause problems with your ISP's uplink. Other than that, I think it would work well.
Sign the packets and they can only DoS you. And I'm hoping you're not suggesting DRM-ing them, as the whole point of this exercise is the assumption that customers will pay for better service.
Hmm... Could you explain how that works?
Specifically -- what about that Alienware made you more likely to be geeky than any other PC?
Or is it that you resent me calling you a "Geek Wannabe", even if you now realize how dumb an Alienware purchase is? I'll admit people can grow and change, but whenever you bought that Alienware, you were either a Geek Wannabe of some sort, or a complete moron with your money.
Maybe not, but it's a simple matter of economics. I'm not generally a hardware geek either, but I do my homework when I make just about any purchase, or I talk to someone who has. It is absolutely worth my time to do the research, and even assemble a machine myself if need be, when the price difference is $1000 or so for an otherwise identical machine.
This applies to other kinds of geeks as well. If I pick up Top Ramen at, what, $2 for a 12-pack, cook it, and serve it to you in an oriental-looking bowl, branded "Naruto Ramen," and charge you $50 for it, well, you got ripped off. If I take a $150 air conditioner, slap a sticker of an alien on it, and sell it to you as an "Alienware cooling system" for $500, guess what? You got ripped off.
Now, maybe you've actually reached the point where you make so much money that the time spent comparison-shopping is actually worth more than the thousand dollars or so you lose by going with Alienware. Or maybe I'm out of it and Alienware is actually charging reasonable prices now. Neither seems likely.
I am not normally so reflexively insulting. I'm a rabid Linux zealot, but if you have to use Windows, I can understand. I'm even more rabidly anti-DRM, but I can understand just wanting to plug in your shiny new Xbox 360 and not think about it. But I honestly cannot think of a good reason for buying an Alienware, other than, say, extreme inebriation.
What does that have to do with the current discussion?
For that matter... Are you married? Do you think your wife would consider Alienware a good decision? A thousand dollars for a pretty-looking case, and better-looking and cheaper ones on Newegg for less than $50?
Wait, hold that thought. I have some ch34p r0l3x and v1agr4 to sell you.
Not a huge one, but it is an issue when you consider that you may eventually want to convert your archive to another format, or display it in another format.
That's easy in documents designed to be edited. It's easy to, for example, convert odf to html, or pdf, or plain text. It's much harder to convert pdf to one of these other formats -- I've tried a PDF to text conversion, and a PDF to html conversion, and neither worked the way I wanted.
I can, and have, shown it to be spyware, by one of those links. You know this -- that it sends out statistical information, and that it does so without your knowledge or consent.
What more do I need, a big sign on it that says "WARNING! VIRUS.EXE!!!"
I see "vulnerabilities fixed". Nothing about how many were actually exploited.
Saying "this many vulnerabilities were fixed" is an even less relevant metric than "this many machines were exploited", because fixing a vulnerability is a good thing. How many vulnerabilities are still out there for Windows, unpatched, maybe undiscovered? Doesn't it make sense that Linux, with its source available, would be easier to find vulnerabilities in (and fix them)?
Putting the filesystem stuff here:
Right. This is actually intelligent, as you say, because it doesn't have to write anything to "page out".
In fact, this would more accurately not be called "paging" so much as having stuff expire from a cache.
In any case, I do think that having a pagefile (or swap space) makes sense, if the kernel is at least sometimes more likely to swap something out than to expire something (executable or not) from the cache. But I don't see the value of putting it in RAM -- the whole point of a pagefile is to provide more storage for when you're low on RAM, or to let the OS use the RAM for something else.
Linux apps tend to use text configuration files for configuration. Storage is in whatever format they want, usually binary (more like .dat), but configuration doesn't need to be fast.
For example: My Postfix server has a configuration split across several files, some of which I've edited, some of which I deliberately have not. It reads them when it starts up, which is basically once per Postfix update or kernel update, and it reads them when I make a change. It then stores its configuration in RAM.
(Postfix, by the way, is an example of how to design a Unix app securely. It's split into many small cooperating processes, many of which are run in a chroot which cannot be broken out of, because the app is not running as root, and there are no executable files in there -- meaning your method doesn't work.)
Well, first of all, on a machine with 8-16 gigs of RAM, I doubt the Photoshop guys are going to have any trouble. I'm actually fairly sure the Windows pagefile has a size limit anyway, by default.
But that's the point -- You were advocating putting the pagefile on a ramdisk, which makes absolutely NO difference for the Photoshop guys. In fact, it may even slow them down, versus not having a pagefile.
Well, like I said, if they have that much knowledge and control over virtual memory, I see that as a design flaw. Processor affinity and thread priority is one thing, but the only place I see a point to an app knowing about swap is for it to explicitly mark a particular page as RAM-only, due to it containing sensitive information that shouldn't touch disk unencrypted.
I may be missing something, but I just can't think of another place where it's a good idea for an app to know about the OS pagefile (or swapspace). Can you?
I know. Every OS has some form of sync. I'm just saying that if transactions are implemented as I suggest, I don't want to lose that feature.
Good. So...
What I would recommend is making the ramdisk as small as possible (but no smaller), and turning off the pagefile if you can, otherwise sticking it on the ramdisk and turning the size limit way down on it.
Even so, I would still e
I thought I'd get rid of this stuff first, so I can get on to the filesystem stuff. And please don't just reply to random posts of mine, completely offtopic like that -- I wasn't ignoring you, I simply didn't have a functioning machine for awhile (hardware).
Burden's on you to prove that it isn't.
If it is malware, and I download it, then my system is compromised, and/or I have to spend a lot of time setting up a sandbox for it.
If it's not malware, and I refuse to download it out of paranoia, there's no huge loss to me. Certainly nothing on the order of what I might have lost, were it malware.
Right, but they never made that clear, which means they never particularly cared whether I'd know about it or not.
Also, I'm pointing to this as a way of questioning their credibility, same as the security hole in their own software. I'm not going to trust security testing software (or its results) from an organization that can't secure their own software and intends to collect data without my knowledge or consent.
I know about this from the other articles you linked to. CIS said nothing about it themselves.
It's not needed on my end, except for running untrusted software like you've suggested. So, I'd rather not learn it unless I have a good reason to.
Well, I did use chown/chmod, as well as su/sudo. So, saying I used a "SINGLE" layer of security is deceptive at best.
You're very good at sensationalist writing, and that has a place and a time -- advertising, maybe. But it has no place in a technical discussion.
What's more, you're innaccurate here. You can put all the buffer overflow vulnerabilities you want in an app which runs as non-root, and it still won't be able to gain root or escape the chroot jail.
What that app needs is a buffer overflow vulnerability in the kernel itself, or in an app which runs as setuserid root. About that, you're right, but the way you've phrased it, I wonder if you really understand what you're saying.
You're also missing the "not worth my time" argument, especially true this weekend... which was when I was planning to do this, but deadlines and more deadlines, not having a computer kind of delayed that project...
Try it yourself.
No, really. If you're half as paranoid about security as you should be, you won't trust any photo anyone posts here. The only way you'll get a score you can trust is to run the tool yourself. For all I care, get an install CD in the mail and run it within the live environment...
But here's the point I seem to be having difficulty communicating with you: Neither this test, nor any test like it, can really test cross-platform. Suppose for a moment that Linux didn't support ACLs -- in that event, any reasonable cross-platform security test would omit a check of ACLs being enabled on Linux.
So, d