That is self resolving. If he doesn't keep his box secure then he'll get burned and learn to not do that in the future.
Except that his box may go insecure for a very long time, and even once it's compromised...
It also doesn't solve the problem where it's a lot more work to keep it secure. So it's a choice between being insecure, and having someone who works full-time on keeping the box up-to-date.
And how many really should be updated without knowing anything about the update?
If you've constrained it to security updates, I'd say, all of them. If you haven't, most should still be safe for minor version upgrades. The ones you really don't know anything about shouldn't hurt, or shouldn't be on your server in the first place.
An example of something that should always be safe to upgrade: tzinfo. Tell me why any sysadmin should waste more than a few seconds of brainpower on tracking tzinfo updates.
I figure it'd be better practice to keep the daemons up to date, but don't modify the other software unless there's a really good reason.
Even if you artificially restrict which things you'd like to keep updated, it still makes sense to have a tool to help you keep them up-to-date, rather that subscribing to dozens (or hundreds) of mailing lists.
That's the thing, in all of those examples some users will almost immediately need to know more advanced details. Video codec choice matters since a) anyone can see differences in quality, b) storage space and download speed come into play, c) not all computers are configured to play all codecs, and d) with moderate quality (or higher) h264 hardware acceleration is essentially a requirement.
Some users, yes.
Many users will throw their hands up, decide it's too complicated, and simply not use the software, if the word "codec" is mentioned at all. And these users have a point -- while it does affect them, you could probably make a sane default that'd make sense for 99% of what anyone wants to do.
That is unnecessarily difficult. It's rare for "advance" settings to need to be configured independently. By allowing that option you're forcing the user to learn about all of them in detail.
I don't see how.
If they see everything they need immediately, that's fine. If they click "advanced" or "more detail", they get another level. Especially if these are scoped to a given task, or section of the config -- for instance, a user who really does need to tweak codecs will probably look under things like "video quality", and click "more detail" until they see the option they need. A user who doesn't, shouldn't need to see more than the fact that the "video quality" tab exists.
The point is not to always show the advance interface, it's to integrate the options into the default one in a way that retains ease of use. It's harder to do, but it makes for better programs.
I'd argue it's not always possible.
Probably the canonical example would be MS Word. They've managed to emphasize what most users will need to do, and most users will show each other how to find the features they need. Go beyond that, though, and everything's just in a giant mess of menus.
Now, it's possible that they could come up with a way of organizing and integrating those features such that new users aren't intimidated by a ton of features, but if you need a given one, it's exactly where you expect it.
But try it. The sheer number of features alone makes that difficult or impossible.
Oh, and if you don't already know... there's a school of thought that there's an ideal number of interface elements you should put on the screen at once -- a certain number choices a user can actually process at once. It's something like 7. If you've got 50 or 100 features, how do you pack that into 7 choices? Seems to me, you have to subdivide it somehow.
If users can't run the software then there's lots of motivation to fix the bug. If package maintainers are complaining then it's going to be a lot lower priority.
Unless package managers are complaining that they can't include the latest version because of a bug. Thus, users can only run older versions of that package, not newer ones. I'd hope that would be some motivation.
I figure the dude with a single linux server sitting in the corner of an office might be tempted to blindly upgrade everything.
That's true... on the other hand, if he did the opposite -- blindly not upgrade everything -- he'd leave himself wide open to security vulnerabilities.
And if he was forced to upgrade manually (without package management), he'd probably upgrade far less often, even when it was a critical security issue.
Servers, for security and performance reasons, should only run the absolutely essential software. That should be trivial to maintain with or without package management.
Even very small servers have over 300 packages installed. Even if I assume that a fair number of these aren't needed, and could be stripped out, it's still going to be over a hundred packages.
Trivial to maintain with package management. A bitch to check 100 different sites (or subscribe to 100 different mailing lists) without package management.
Too much abstraction leakage might cause security or performance issues.
Shouldn't cause many security issues, unless the issue is automatic updates, and those can be turned off.
And performance, well, if I've got the caching filesystem handled by the kernel, that should take care of the performance issues.
This assumes that the new way doesn't become wide-spread.
That is true, but the new way is becoming wide-spread -- and it's not my idea.
And I don't think we should hold back progress because of those growing pains.
Users, for the most part, just want to get something done ASAP, and try to learn as little as they can get away with. I figure education can't be effectively front loaded, you need to teach it along the way.
Still doesn't preclude teaching what's more important along the way.
Actually, what's major and what's minor is entirely subjective and differs with each user.
To an extent.
For example, if I'm unpacking an archive, or playing a movie, what codecs or decompression tool is used is completely beside the point. The point is understanding that this is a movie, or that this is an archive (and not a folder) if it's going to be unpacked...
Take h264 video encoding for example. There are a ton of options, and several different user requirements. You can change resolution, bitrate, CBR or VBR, and a great many more advance options. The thing is, every user wants the best video quality possible under their individual conditions.... H264 specifically gets around this with encoding profiles.
So, what would make sense is to have varying levels of complexity. First have it just pick something, then if the user digs deeper, they find profiles, and if they dig even deeper, they can tweak each setting by hand.
The ability to tweak each setting by hand shouldn't be removed, but users shouldn't be required to tweak these settings. This is essentially why the "more details" button exists.
Well, by hiding things away with a click what you do is steepen the learning curve.
On the contrary, I think it helps the learning curve. Immediately exposing users to all details leads to information overload, and the perception that this application is "hard".
Users can't do much with the default interface, but are overwhelmed by the advance one.
A package manager sending a HUP signal would have worked. However, this requires applications to be written with that in mind, so it's not quite expandable to novel applications.
All it requires is that an application be written with some way to signal a reload/reconfigure without a restart, or just a graceful restart. It doesn't have to be specifically HUP.
And while it's clear that not all apps would support this, it's also clear that any app which would support this through its own plugin system -- yours supported downloading and then reloading that -- it shouldn't be too hard to adapt the app to allow external sources to signal a reload, and it's a useful feature in general.
Looks like we differ in opinion here. I'd see that as sacrificing future improvement for present convenience. If an application is broken, it's broken, and IMHO it'll waste an infinite amount of package maintainer's time to fix bugs with every release that the program author shouldn't be introducing in the first place.
I don't think that's what I was suggesting.
I'm saying the bug absolutely should be fixed upstream. But until it can be, if the package manager can fix it, that's a good thing.
And having fixed releases, with only security updates between them, is one easy way to avoid such problems from occurring, at least on end-users' systems.
The experienced Privoxy users recognize that the lack of GZip support is a problem, and the experienced OpenWRT users know how to create such a package for OpenWRT. Unfortunately, these two circles have exceedingly little overlap...
Ideally, creating a package should be easy. For example, if you know how to configure/make/install, you're most of the way to understanding how a Gentoo ebuild works. Rubygems are even easier.
I'd always figured package management was within the realm of desktop users, where a sub-percent performance difference would be absorbed within unrelated bottlenecks.
You'd think so, but desktop users do complain about Ubuntu daring to use so much Python, as it's slower than C.
Besides which, there are people with older systems, people trying to use the system for gaming, etc etc...
Believe it or not, this is actually easier to manage in most server environments, as you can horizontally scale them -- literally throw more hardware at the problem. You can do that with desktops, to an extent, but users will resent having to buy more hardware when they don't need to -- and I agree, why does ACT need a gig of RAM, for example?
Servers might be easier to administer using package management, but I'd suspect that causes more problems than it fixes. Example: "Oops, that last update killed the webserver plugin, and reverting isn't an option since the old version can't be installed with the newer versions of everything else present
A decent package manager should make it possible to roll back the entire last operation -- including the newer versions of everything else present. Not that I know how to do this, I'm just saying, it should be possible.
But there are a couple of other concerns here:
First, this doesn't happen often. In my experience running Linux servers, I almost never see a minor upgrade (a security patch) break anything. Major upgrades sometimes do, but then, I'm ready for those (proper backups ahead of time), and by "sometimes", I mean "about as often as I've seen a Linux server crash," which is very close to "never."
Second, a package manager can theoretically deal with this better than a pure sysadmin can. Even disregarding the "roll back that last thing I did" feature, I should be able to tell it to roll back to an older version of the webserver. It should then tell me about conflicts, and suggest ways to resolve them -- for instance, remove this plugin, or roll it back as well.
God doesn't punish anybody anymore than an apple tree punishes an apple that falls to the ground.
An apple tree is not omniscient or omnipotent. If god is, he again either punishes or allows suffering to happen as a kind of punishment.
I think the difference between punishment and an omnipotent being allowing punishment to happen is largely subjective.
God abhors sin and apparently considers it much worse than death, even the death of a baby in the fire.
This is another case where I think I can show that you or I are better than God.
Which is worse: Saying "You look great in that dress!" or calmly watching a baby slowly burn to death, while doing nothing about it?
Oh, and false dichotomy -- why does your god allow babies to die in fires? How is that stopping (or preventing) sin from happening? It's not like we either have sin or babies dying in fires -- obviously, we have both, and if God was real, we could have neither.
Because you are sinful, you are running away from God.
Running away would be closing this thread and never returning.
Or, more significantly, running away would have been to stop thinking about these questions when I started getting answers I didn't like -- to continue to believe, and ignore all the reasons I had not to.
there are many who have become true Christians when they were at the bottom of a foxhole under enemy fire. I will pray, that God will put you in a "foxhole", and you cry out to God to save you.
The Military Association of Atheists & Freethinkers, an atheist organisation, opposes the use of this phrase. They have adopted the catchphrase of "Atheists in Foxholes" to emphasize that the original statement is just an aphorism and not a statistical fact.
I hope I am never in a foxhole, but I doubt it would make me find faith -- though it might increase my use of a few habits that I've been slow to break, like the phrase "Goddammit."
But your core point here, that this is the best way he could help people to search for him, shows a lack of imagination. At least in my case, I would be far less likely to believe in a foxhole than I would if, for instance, I actually met Jesus, or if I prayed for something physically impossible or incredibly improbable, and it happened -- especially if I could make it happen reliably, simply through prayer.
The religious leaders of Israel did not believe in Jesus resurrection because they did not want to believe. A person who has made up their mind not to believe, will reject any and all evidence, just as they did.
That has something to do with the above, but also does little to explain why bad things happen to good people, to the truly faithful. The idea of "testing someone's faith" seems bizarre -- again, wouldn't an omniscient god know whether they were truly faithful without forcing them to undergo that test? I'm fairly confident that I would survive castration, but I'm not eager to test that -- why would a loving god test us that way?
What's funny is, you posted this in reply to "no testimony is sufficient..." without actually providing sufficient testimony. Instead, you've said something that's demonstrably wrong:
Of all religious leaders and groups that have ever come and gone on this earth, only Jesus has made the claims to deity,
I'd like to use this opportunity to stress, again, why it's important to back up your beliefs with evidence -- if nothing else, it's a means to help you to believe things are true. And I'd like to stress, again, that it's important to believe as many true things as possible and as few false things as possible.
Here's a short list of religious leaders, real and po
Are they really? Or are they just getting paranoid?
After all, while I do get the arguments for using h.264 for web content, Theora is easier to support everywhere, and Safari is the only browser I know of which supports HTML5 but not Theora. Why? Because they're paranoid about patent trolls.
Modularity is a good thing, if you draw the modules in the correct place. And ZFS is indeed modular...
Take all of this with a grain of salt, as I haven't actually used ZFS, only designed something similar, then found ZFS did it already, then decided I didn't care and used Linux anyway.
My understanding is that there's a storage layer, where you can simply request storage for some purpose, and it gives you that storage with an id -- kind of like an inode. You could build a filesystem on top of that, managing all the metadata yourself. Or you could build something else -- a database, for example. And the filesystem layer still handles all kinds of things, like permissions, directories, etc, it's just that the allocation has been separated out.
Thus, the allocation layer can make smart decisions about things like which disk to allocate something on, or what actually needs to be replicated, etc.
For example: Think about any kind of RAID, even striping. If RAID can only work with whole volumes, that means the entire discs have to be synced (in RAID1) or checksummed/paritied (in RAID5), including free space. In ZFS, not only can you avoid replicating free space, but I believe you could also specify which files are important and which ones aren't -- and only the important ones are replicated, thus saving space on the ones which aren't.
Another, more theoretical example: SSDs are a bunch of hacks on top of hacks. See, erasing and then writing to the same flash cell over and over wears it out, and there's no seek time. Largely because of Windows, I would guess, SSDs these days implement wear-leveling in the firmware, so that the OS sees only a logical disk that pretends to be a hard drive. But this means they always have to keep a number of cells unallocated, and it slows down writes to have to erase each cell before writing.
So, someone came up with the ATA TRIM command, where the OS could tell the SSD which blocks are no longer in use, and the SSD can actually erase them.
Compare this to the old solution -- implement wear-leveling in software. There were a few filesystems written to run directly on the flash, and it was actually the filesystem doing the wear-leveling. This meant the filesystem could intelligently spread new writes over free space, instead of having to keep some arbitrary number of blocks in reserve...
This is getting fairly technical, and also boring, as ultimately, it's not that much of a difference. But this just shows the potential modularity of a system like ZFS. See, if ZFS separates out the allocation, that means you could replace that part without touching the filesystem, database, or anything else. And you could probably replace it with something that knows how to deal directly with a flash device -- something which, for example, erases blocks as ZFS snapshots are deleted.
By default, Pagefile.sys is equal to your total physical RAM. So, if you have 4GB of RAM, you will have a 4GB page file.
WTF? Why?
If I had 2 gigs of RAM and a 2 gig pagefile, and I upgrade to 4 gigs of RAM, the logical thing to do would be to reduce my pagefile to 0 -- those 2 gigs that I used to have to swap, I now have the RAM to cover.
sounds like you have 4GB?
Yep.
I'd recommend shrinking the size and using a Flash device with Readyboost. It makes a huge difference in page file performance.
...why? I've got an SSD...
My system is on a 60GB SSD, but I moved the 8GB Pagefile to a hard disk and dedicated a fast CF card to Readyboost, and the performance is just fine.
...I don't see how that improves things, over leaving both on the SSD.
Regardless, I doubt it'll provide much improvement. 4 gigs of RAM is plenty to just boot, and the Windows install I have is mostly just for games. I've recently discovered that a bootable Linux DVD actually works fine for games, so I don't think any sort of disk performance is the bottleneck to anything other than load times -- and 30 seconds instead of 10 seconds isn't that bad.
Step two: Construct laptop to ignite thermite on any attempt at tampering, or when the self-destruct happens.
Step three: Summon just enough courage to reveal the wrong password when it's convincing to do so. Yes, it's going to hurt, but now they can'tget any more out of you, no matter how painful they make it. And if you were tempted to reveal the real password, realize that either way, they might keep torturing you anyway.
This could be scaled down -- rather than the laptop hard drive, it could be a small USB device which the keys never leave. I'm not sure what's known about recovering erased data from flash, but it wouldn't be hard to simply erase the block with the key on it.
Nah, they could still compromise your PC to upload the USB data later.
First, let's consider the case where we take GP literally -- it's just the bootloader on the USB drive.
So no, they can't compromise your PC, because there's only encrypted data on your PC. There's also nothing sensitive on the flash drive.
Or, take my last laptop: I had an encrypted Linux partition, and/boot partition was a USB key. I had my keys, unencrypted, on the initial ramfs. So if anyone was able to touch the USB key, ever, they could've done exactly this attack.
But I removed the USB key whenever I wasn't actively booting from it, and kept it in my pocket.
I also had a BIOS password, and the USB was the only configured boot device.
But if they'd been able to access my laptop, there's really not much they could do in the time they have access to it -- it'd have to be a physical compromise, and it seems like that'd be hard to do universally across all laptops.
This is arbitrarily limiting compatibility though. And with less compatibility between versions there's a greater risk of incompatible combinations.
It's also guaranteeing compatibility where it makes sense -- old versions of the plugin may work with new versions of the app. But new plugins for the new app shouldn't necessarily be forced to be backwards-compatible.
restarts in quick succession (e.g. installing multiple plugins) would get the bot temporarily banned from IM servers, rendering it incommunicado.
Or you provide a list of plugins, and allow the restart only once all are successfully installed. Most package managers have the concept of a trigger that happens only after all current operations are finished -- or at least, all current operations with that trigger.
Reloading into the same process, though, could be easily accomplished with a package manager -- the traditional way would be to place the new plugin script where plugin scripts are expected, and then send a HUP signal to the bot, to tell it to scan its plugin directory and load (or reload) any new (or updated) plugins.
So, it doesn't save you much, but it does save you dependencies (somewhat) and downloading. And if it was something like Rubygems, it'd actually save you those dependencies.
The advantage of doing it that way is that the distro is at least a central place where you can be sure that one stable release of an app cooperates with another stable release.
IMHO, this is a bug and should be fixed rather than mitigated with package management.
I would say it's not either-or. It is a bug, and should be fixed. But distros can at least prevent end-users from ever seeing this bug, and the easiest way to do that is to freeze packages.
It's similar, by the way, to software releases in the first place. A few programs only maintain a public SVN repository (or something similar), and do no releases. Most programs try to do releases, and the way it usually works is, you call a feature freeze, and from that point on, you may only fix bugs, not introduce features, until it's reasonably bug-free. Then you release it, and only release bugfixes for that version until the next version is completely ready.
The only real difference is that distros can treat the entire distro as a single piece of software, in that respect, much as Microsoft treats Windows as a single piece of software.
My "favorite" example of this was with Privoxy on OpenWRT. Basically, OpenWRT was lagging years behind Privoxy releases, and didn't enable gzip compression until recently.
In this case, I'd hope that someone would release a new privoxy for OpenWRT, with gzip enabled. If OpenWRT used a decent package manager, such a third-party version should be possible to integrate.
Your ideas on implementation of a better package manager sound solid. The devil, of course, is in the details, but I see no obvious problems.
I see a few.
First is performance. The initial implementation would probably build most of the OS on top of a FUSE filesystem. I don't think this would be a problem for me, personally, but many users would complain about performance. To be taken seriously, I'd have to implement the cache at least partly in kernel space.
Second is time. That is, I have none. I really want to do this right -- that is, I want to do it personally, and I want it to be done right. I don't even have time to half-ass it now.
IMHO learning is impossible unless you have at least a rough idea of what is going on. Application installation obviously isn't a trivial operation, so if the package manager makes it seem that way then it's too dumbed down.
That really depends on the application. Sometimes users have really profound insights that are born out of ignorance.
Why does God allow anybody to die? The Bible tells us that death came into the world when the first man sinned.
In other words, God likes to punish people for things they didn't do, because an ancestor did?
Besides that, God doesn't look at death the same way you do. Death is not the cessation of being, but a mere separation.
And fire is not merely death, but an incredibly painful death.
So, your god burns babies to death -- or merely burns them until they're a pile of ash, and then resurrects them to eternal life -- because of something Adam did.
And you're ok with that.
Is that something you would ever, ever do, even if you had the power to resurrect them to eternal life? Wouldn't you at least knock them out first, if you had to kill them, to be merciful about it?
God doesn't want to torture you, but it would be torture for you if he forced you to be in his presence forever.
Firstly, you cannot possibly know that. Certainly, there was a time when I didn't believe, but wanted to. At that time, if he turned out to be real, I'd certainly want to be in his presence.
Secondly, that's a false dichotomy. You're implying that the only option is to separate me from him forever for my disbelief without evidence, or force me to be near him.
He could, y'know, provide evidence, so I could make an informed decision. If he doesn't want to do that in this world, perhaps a good opportunity would be after death -- yet according to you (correct me if I'm wrong), after death I'll be cast into a lake of fire, without the opportunity to actually see a few angels and demons and change my mind.
Therefore, God allows or even sends trouble, in order for people to search again for him.
Is that the best possible way he could think of helping people search for him?
Especially considering that for some people, this has the opposite effect? Many Jews who survived the Holocaust became atheists, as they could not believe that any loving god would allow that to happen.
In our church we often hear the testimony of visiting missionaries from Third World countries, especially Africa. They testify of experiencing miracles, were lame people walk again, blind people see again and even dead people come to life again, in response to fervent prayer. You will probably tell me that their testimony is false.
Something like that. Here's a quote from David Hume:
no testimony is sufficient to establish a miracle, unless the testimony be of such a kind, that its falsehood would be more miraculous, than the fact, which it endeavors to establish.
Can you tell me honestly that these missionaries are so reliable that for them to be wrong would be more miraculous than for a dead man to rise again?
Also worth mentioning, none of those things you mentioned are limbs regenerating. There have been examples of similar things with entirely secular explanations, where lame people began to walk, where blindness was only temporary, and where someone was mistaken for dead.
Amputees are chosen as an example, because it's usually quite easy to prove that someone is missing a limb, and later, to prove that the limb is there.
Jesus enemies attributed his miracles to the devil rather than God.
And what is your reason for believing him, rather than his enemies?
That is to accurately foretell the future, especially thousands of years in advance.
It seems like what you've quoted here is a declaration of the end, not evidence of anything...
Job 26:7 He stretches out the north over the empty place, and He hung the earth on nothing. Job 26:10 He has described a circle on the surface of the waters to the boundary of light with darkness.
And about the technology field. Get this into the distorted reality in your head: Women don't like engineering!! Sure, there are exceptions. But women simply like other things. Because they are women!
Bullshit. And I'm a guy.
The differences are largely cultural and stereotypes, which you're helping to promote:
Engineering as a ideal job for your life, is a male ideal, by the way!
Why must this be the case?
The best way to see what genders like, is to look at the smallest children, offer them toys for both genders, and see what they prefer to play with. They actually tested this.
It still doesn't show a fundamental difference. For example, I bet girls like pink and boys like blue, but that's taught to them practically from birth -- in many cases, their first room is going to be full of blue for boys, or pink for girls.
The only really weird thing is, that "building" somehow is seen as better than "caring". And the weirdest thing is, that the most hard-core feminists strongly support this very male-centered view on ideals.
"Better"? I wouldn't say that...
Who was well known for caring? I can think of a few names off the top of my head -- Mother Teresa, Gandhi...
Now, who was well known for building, well, anything?
Can you name even one?
I mean, physicists come to mind much more rapidly -- Einstein, Feynman, Hawking...
If you count software, there's Linus... and RMS, but he's not really famous outside his field... and... uhm...
Maybe it's just me, but it seems very much to me that caring is seen as much better than building.
The difference is the scale, the amount of ambition. Tim Berners-Lee changed the world with his software. Gandhi changed the world with his caring... but being a stay-at-home mom isn't changing the world, and it certainly doesn't make you Gandhi.
I don't mean this as a slight against stay-at-home moms. I'm just saying, feminism used to have a point -- the appeal of wanting to create something larger than yourself is not a male-only thing. Where the hard-core feminists lost their way is in assuming that any girl who actually wants to be a stay-at-home mom has been brainwashed into that point of view -- and to prove the point, there are men who are stay-at-home dads.
Back to your point: It may very well be that women don't like engineering because they don't like engineers, not because they don't want to be one. There are many factors, but I think it's largely momentum. Engineers are seen as geeks, and find it harder to meet women in the first place. A woman shows up in the workplace, the engineers already know she's smart and they'll share some common interests, and she's the first woman they've seen in awhile...
So, she's going to get hit on a lot. Uncomfortable at best. So she'll tell her friends about it, and the stereotype of engineers being pervs is perpetuated. Eventually, she quits -- or if she doesn't, her friends never become engineers -- so "women don't like engineering" is perpetuated.
This vicious cycle continues until you either get a woman with tough enough skin to handle it, or a group of engineers who have collectively grown enough maturity to treat that woman with respect. Even here, it will take decades of things like this happening to reverse the study, to slowly bring more women into the field.
So I agree with you about the lap dancers, somewhat. But I do think that some things have to change if we want more women engineers -- and we do, if for no other reason than that it increases the number of potential engineers, meaning we'll hopefully get better ones.
Yeah, you could write new clients that make it work like twitter or IM or email. But those things already exist and work just fine.
Well, and you can extend it. And while IM and email exist, they aren't particularly integrated, nor are either of them at all integrated with a wiki...
So I guess I'm not sure what the hype is about exactly.
Well, let me put it this way...
It could turn out to be like XML, which was incredibly generic, everyone was blown away by the possibilities, and then we came back down to earth and realized that it doesn't really revolutionize anything. It's useful for what it is, but it was completely overhyped, and most places it's used, there's something better (JSON, YAML, protocol buffers, etc).
Or it could turn out to be like HTML and HTTP -- still largely misunderstood, but anyone who has a concept of what they are should understand what an impact they had.
I think it's going to be somewhere in the middle -- not nearly what HTML was, but consider: "Yeah, you could make it work like email. But that exists and works just fine." Webmail was certainly useful.
If something about the underlying OS changes in an update, the scripts may need to be updated.
This is also true for the app itself. The difference is, these scripts are usually managed by the distro.
Likewise, if the parent application or plugin changes then you could quite possibly need to maintain scripts for the new plugin version installing to an old parent, vice versa, old to old, and new to new.
Or you simply decide that once you update the parent application in your distro, new versions of this plugin will only work with the new parent application. So you only need "old-to-new", and that's only if the plugins remain binary-compatible.
Fixing applications so plugin systems are consistent would definitely work. It should probably be done anyway. But I'm doubtful programmers will all break plugin compatibility for that reason.
Most applications are already consistent, and the few which aren't are also not that far off. You mentioned PHP -- it really would not be difficult to make this consistent and preserve compatibility.
I suppose I once wrote an extremely modular chatbot that was designed to be fairly autonomous and remotely upgradable. Therefore, it installed, uninstalled, and hotswapped plugins as it ran. Each had mandatory settings (e.g. security level) and as such had to be mentioned in the config file. The thing is, settings were only loaded at launch, and kept internally afterwards, so a shutdown would be necessary for an external package manager to change anything.
A few incremental changes:
First, change your app so that rather than reading only one config file, it is capable of loading a config directory. This could be as simple as adding a config directive to the master config file that says "Load this directory."
Next, add a sub-config-file to each plugin. Not terribly difficult to maintain -- they probably already have examples in their README, at least.
Next, add metadata to each plugin to restart the chat server on install. Even if your package manager forces you to script it manually, it's pretty much an "/etc/init.d/mychatapp restart".
I believe this is more or less how Debian manages Apache plugins.
a shutdown would be necessary for an external package manager to change anything. This would be undesirable given the nature of the program
So how would you normally load a new plugin without shutting down?
I've seen too many repositories, download sites, and the like come and go to want to rely on them indefinitely.
Ah, so it's the centralization of download, which isn't necessary for package management, though it's usually how it's done.
And you could also look at which ones have been around the longest to get an idea of which ones are likely to continue to be around.
The lag is a fundamental part of introducing a third party to the interaction. Even if you had an obsessive package maintainer that did nothing but package stuff at 4:03 am with a 5 minute turn-around time, it's still a delay.
I've seen Gentoo add packages within hours. I can live with that, since I certainly am not doing nothing but checking for updates at 4:03 am every 5 minutes.
And again, third-party repositories can remove even this lag.
I think that's something for the application developer to fix. If an application is misbehaving a better option is to not use it and let free market forces/natural selection take place.
Perhaps, but remember that this isn't strictly natural selection -- unlike the real world, we are designing and developing these programs intelligently.
So, for example, if a program is set up really weirdly, and Ubuntu fixes it to match FHS, and the developer has more Ubuntu users than other users, the program might actually be fixed, not simply replaced. If a
Slashdot Mirror
Not yet.
...I was just really, really curious if someone had the domain...
Damn... now you've given them ideas... (shudder) Neanderthal porn!
I believe that's Rule 35: if it doesn't exist on the internet, it must be created.
My fault for being an early adopter, but my Dell XPS with, according to hdparm:
Model=SAMSUNG SSD RBX Series 128GB M , FwRev=VAM05D1Q, SerialNo=DFF1L0A835SE835A1948
This neither seems to support trim nor seems to have any firmware upgrades at all.
That is self resolving. If he doesn't keep his box secure then he'll get burned and learn to not do that in the future.
Except that his box may go insecure for a very long time, and even once it's compromised...
It also doesn't solve the problem where it's a lot more work to keep it secure. So it's a choice between being insecure, and having someone who works full-time on keeping the box up-to-date.
And how many really should be updated without knowing anything about the update?
If you've constrained it to security updates, I'd say, all of them. If you haven't, most should still be safe for minor version upgrades. The ones you really don't know anything about shouldn't hurt, or shouldn't be on your server in the first place.
An example of something that should always be safe to upgrade: tzinfo. Tell me why any sysadmin should waste more than a few seconds of brainpower on tracking tzinfo updates.
I figure it'd be better practice to keep the daemons up to date, but don't modify the other software unless there's a really good reason.
Even if you artificially restrict which things you'd like to keep updated, it still makes sense to have a tool to help you keep them up-to-date, rather that subscribing to dozens (or hundreds) of mailing lists.
That's the thing, in all of those examples some users will almost immediately need to know more advanced details. Video codec choice matters since a) anyone can see differences in quality, b) storage space and download speed come into play, c) not all computers are configured to play all codecs, and d) with moderate quality (or higher) h264 hardware acceleration is essentially a requirement.
Some users, yes.
Many users will throw their hands up, decide it's too complicated, and simply not use the software, if the word "codec" is mentioned at all. And these users have a point -- while it does affect them, you could probably make a sane default that'd make sense for 99% of what anyone wants to do.
That is unnecessarily difficult. It's rare for "advance" settings to need to be configured independently. By allowing that option you're forcing the user to learn about all of them in detail.
I don't see how.
If they see everything they need immediately, that's fine. If they click "advanced" or "more detail", they get another level. Especially if these are scoped to a given task, or section of the config -- for instance, a user who really does need to tweak codecs will probably look under things like "video quality", and click "more detail" until they see the option they need. A user who doesn't, shouldn't need to see more than the fact that the "video quality" tab exists.
The point is not to always show the advance interface, it's to integrate the options into the default one in a way that retains ease of use. It's harder to do, but it makes for better programs.
I'd argue it's not always possible.
Probably the canonical example would be MS Word. They've managed to emphasize what most users will need to do, and most users will show each other how to find the features they need. Go beyond that, though, and everything's just in a giant mess of menus.
Now, it's possible that they could come up with a way of organizing and integrating those features such that new users aren't intimidated by a ton of features, but if you need a given one, it's exactly where you expect it.
But try it. The sheer number of features alone makes that difficult or impossible.
Oh, and if you don't already know... there's a school of thought that there's an ideal number of interface elements you should put on the screen at once -- a certain number choices a user can actually process at once. It's something like 7. If you've got 50 or 100 features, how do you pack that into 7 choices? Seems to me, you have to subdivide it somehow.
If users can't run the software then there's lots of motivation to fix the bug. If package maintainers are complaining then it's going to be a lot lower priority.
Unless package managers are complaining that they can't include the latest version because of a bug. Thus, users can only run older versions of that package, not newer ones. I'd hope that would be some motivation.
I figure the dude with a single linux server sitting in the corner of an office might be tempted to blindly upgrade everything.
That's true... on the other hand, if he did the opposite -- blindly not upgrade everything -- he'd leave himself wide open to security vulnerabilities.
And if he was forced to upgrade manually (without package management), he'd probably upgrade far less often, even when it was a critical security issue.
Servers, for security and performance reasons, should only run the absolutely essential software. That should be trivial to maintain with or without package management.
Even very small servers have over 300 packages installed. Even if I assume that a fair number of these aren't needed, and could be stripped out, it's still going to be over a hundred packages.
Trivial to maintain with package management. A bitch to check 100 different sites (or subscribe to 100 different mailing lists) without package management.
Too much abstraction leakage might cause security or performance issues.
Shouldn't cause many security issues, unless the issue is automatic updates, and those can be turned off.
And performance, well, if I've got the caching filesystem handled by the kernel, that should take care of the performance issues.
This assumes that the new way doesn't become wide-spread.
That is true, but the new way is becoming wide-spread -- and it's not my idea.
And I don't think we should hold back progress because of those growing pains.
Users, for the most part, just want to get something done ASAP, and try to learn as little as they can get away with. I figure education can't be effectively front loaded, you need to teach it along the way.
Still doesn't preclude teaching what's more important along the way.
Actually, what's major and what's minor is entirely subjective and differs with each user.
To an extent.
For example, if I'm unpacking an archive, or playing a movie, what codecs or decompression tool is used is completely beside the point. The point is understanding that this is a movie, or that this is an archive (and not a folder) if it's going to be unpacked...
Take h264 video encoding for example. There are a ton of options, and several different user requirements. You can change resolution, bitrate, CBR or VBR, and a great many more advance options. The thing is, every user wants the best video quality possible under their individual conditions.... H264 specifically gets around this with encoding profiles.
So, what would make sense is to have varying levels of complexity. First have it just pick something, then if the user digs deeper, they find profiles, and if they dig even deeper, they can tweak each setting by hand.
The ability to tweak each setting by hand shouldn't be removed, but users shouldn't be required to tweak these settings. This is essentially why the "more details" button exists.
Well, by hiding things away with a click what you do is steepen the learning curve.
On the contrary, I think it helps the learning curve. Immediately exposing users to all details leads to information overload, and the perception that this application is "hard".
Users can't do much with the default interface, but are overwhelmed by the advance one.
So add an intermediate interface.
But even if that
A package manager sending a HUP signal would have worked. However, this requires applications to be written with that in mind, so it's not quite expandable to novel applications.
All it requires is that an application be written with some way to signal a reload/reconfigure without a restart, or just a graceful restart. It doesn't have to be specifically HUP.
And while it's clear that not all apps would support this, it's also clear that any app which would support this through its own plugin system -- yours supported downloading and then reloading that -- it shouldn't be too hard to adapt the app to allow external sources to signal a reload, and it's a useful feature in general.
Looks like we differ in opinion here. I'd see that as sacrificing future improvement for present convenience. If an application is broken, it's broken, and IMHO it'll waste an infinite amount of package maintainer's time to fix bugs with every release that the program author shouldn't be introducing in the first place.
I don't think that's what I was suggesting.
I'm saying the bug absolutely should be fixed upstream. But until it can be, if the package manager can fix it, that's a good thing.
And having fixed releases, with only security updates between them, is one easy way to avoid such problems from occurring, at least on end-users' systems.
The experienced Privoxy users recognize that the lack of GZip support is a problem, and the experienced OpenWRT users know how to create such a package for OpenWRT. Unfortunately, these two circles have exceedingly little overlap...
Ideally, creating a package should be easy. For example, if you know how to configure/make/install, you're most of the way to understanding how a Gentoo ebuild works. Rubygems are even easier.
I'd always figured package management was within the realm of desktop users, where a sub-percent performance difference would be absorbed within unrelated bottlenecks.
You'd think so, but desktop users do complain about Ubuntu daring to use so much Python, as it's slower than C.
Besides which, there are people with older systems, people trying to use the system for gaming, etc etc...
Believe it or not, this is actually easier to manage in most server environments, as you can horizontally scale them -- literally throw more hardware at the problem. You can do that with desktops, to an extent, but users will resent having to buy more hardware when they don't need to -- and I agree, why does ACT need a gig of RAM, for example?
Servers might be easier to administer using package management, but I'd suspect that causes more problems than it fixes. Example: "Oops, that last update killed the webserver plugin, and reverting isn't an option since the old version can't be installed with the newer versions of everything else present
A decent package manager should make it possible to roll back the entire last operation -- including the newer versions of everything else present. Not that I know how to do this, I'm just saying, it should be possible.
But there are a couple of other concerns here:
First, this doesn't happen often. In my experience running Linux servers, I almost never see a minor upgrade (a security patch) break anything. Major upgrades sometimes do, but then, I'm ready for those (proper backups ahead of time), and by "sometimes", I mean "about as often as I've seen a Linux server crash," which is very close to "never."
Second, a package manager can theoretically deal with this better than a pure sysadmin can. Even disregarding the "roll back that last thing I did" feature, I should be able to tell it to roll back to an older version of the webserver. It should then tell me about conflicts, and suggest ways to resolve them -- for instance, remove this plugin, or roll it back as well.
Doing that manually would be much more difficult.
God doesn't punish anybody anymore than an apple tree punishes an apple that falls to the ground.
An apple tree is not omniscient or omnipotent. If god is, he again either punishes or allows suffering to happen as a kind of punishment.
I think the difference between punishment and an omnipotent being allowing punishment to happen is largely subjective.
God abhors sin and apparently considers it much worse than death, even the death of a baby in the fire.
This is another case where I think I can show that you or I are better than God.
Which is worse: Saying "You look great in that dress!" or calmly watching a baby slowly burn to death, while doing nothing about it?
Oh, and false dichotomy -- why does your god allow babies to die in fires? How is that stopping (or preventing) sin from happening? It's not like we either have sin or babies dying in fires -- obviously, we have both, and if God was real, we could have neither.
Because you are sinful, you are running away from God.
Running away would be closing this thread and never returning.
Or, more significantly, running away would have been to stop thinking about these questions when I started getting answers I didn't like -- to continue to believe, and ignore all the reasons I had not to.
there are many who have become true Christians when they were at the bottom of a foxhole under enemy fire. I will pray, that God will put you in a "foxhole", and you cry out to God to save you.
Ah, the "no atheists in foxholes" argument... But read that article:
The Military Association of Atheists & Freethinkers, an atheist organisation, opposes the use of this phrase. They have adopted the catchphrase of "Atheists in Foxholes" to emphasize that the original statement is just an aphorism and not a statistical fact.
I hope I am never in a foxhole, but I doubt it would make me find faith -- though it might increase my use of a few habits that I've been slow to break, like the phrase "Goddammit."
But your core point here, that this is the best way he could help people to search for him, shows a lack of imagination. At least in my case, I would be far less likely to believe in a foxhole than I would if, for instance, I actually met Jesus, or if I prayed for something physically impossible or incredibly improbable, and it happened -- especially if I could make it happen reliably, simply through prayer.
The religious leaders of Israel did not believe in Jesus resurrection because they did not want to believe. A person who has made up their mind not to believe, will reject any and all evidence, just as they did.
That has something to do with the above, but also does little to explain why bad things happen to good people, to the truly faithful. The idea of "testing someone's faith" seems bizarre -- again, wouldn't an omniscient god know whether they were truly faithful without forcing them to undergo that test? I'm fairly confident that I would survive castration, but I'm not eager to test that -- why would a loving god test us that way?
What's funny is, you posted this in reply to "no testimony is sufficient..." without actually providing sufficient testimony. Instead, you've said something that's demonstrably wrong:
Of all religious leaders and groups that have ever come and gone on this earth, only Jesus has made the claims to deity,
I'd like to use this opportunity to stress, again, why it's important to back up your beliefs with evidence -- if nothing else, it's a means to help you to believe things are true. And I'd like to stress, again, that it's important to believe as many true things as possible and as few false things as possible.
Here's a short list of religious leaders, real and po
Are they really? Or are they just getting paranoid?
After all, while I do get the arguments for using h.264 for web content, Theora is easier to support everywhere, and Safari is the only browser I know of which supports HTML5 but not Theora. Why? Because they're paranoid about patent trolls.
Modularity is a good thing, if you draw the modules in the correct place. And ZFS is indeed modular...
Take all of this with a grain of salt, as I haven't actually used ZFS, only designed something similar, then found ZFS did it already, then decided I didn't care and used Linux anyway.
My understanding is that there's a storage layer, where you can simply request storage for some purpose, and it gives you that storage with an id -- kind of like an inode. You could build a filesystem on top of that, managing all the metadata yourself. Or you could build something else -- a database, for example. And the filesystem layer still handles all kinds of things, like permissions, directories, etc, it's just that the allocation has been separated out.
Thus, the allocation layer can make smart decisions about things like which disk to allocate something on, or what actually needs to be replicated, etc.
For example: Think about any kind of RAID, even striping. If RAID can only work with whole volumes, that means the entire discs have to be synced (in RAID1) or checksummed/paritied (in RAID5), including free space. In ZFS, not only can you avoid replicating free space, but I believe you could also specify which files are important and which ones aren't -- and only the important ones are replicated, thus saving space on the ones which aren't.
Another, more theoretical example: SSDs are a bunch of hacks on top of hacks. See, erasing and then writing to the same flash cell over and over wears it out, and there's no seek time. Largely because of Windows, I would guess, SSDs these days implement wear-leveling in the firmware, so that the OS sees only a logical disk that pretends to be a hard drive. But this means they always have to keep a number of cells unallocated, and it slows down writes to have to erase each cell before writing.
So, someone came up with the ATA TRIM command, where the OS could tell the SSD which blocks are no longer in use, and the SSD can actually erase them.
Compare this to the old solution -- implement wear-leveling in software. There were a few filesystems written to run directly on the flash, and it was actually the filesystem doing the wear-leveling. This meant the filesystem could intelligently spread new writes over free space, instead of having to keep some arbitrary number of blocks in reserve...
This is getting fairly technical, and also boring, as ultimately, it's not that much of a difference. But this just shows the potential modularity of a system like ZFS. See, if ZFS separates out the allocation, that means you could replace that part without touching the filesystem, database, or anything else. And you could probably replace it with something that knows how to deal directly with a flash device -- something which, for example, erases blocks as ZFS snapshots are deleted.
By default, Pagefile.sys is equal to your total physical RAM. So, if you have 4GB of RAM, you will have a 4GB page file.
WTF? Why?
If I had 2 gigs of RAM and a 2 gig pagefile, and I upgrade to 4 gigs of RAM, the logical thing to do would be to reduce my pagefile to 0 -- those 2 gigs that I used to have to swap, I now have the RAM to cover.
sounds like you have 4GB?
Yep.
I'd recommend shrinking the size and using a Flash device with Readyboost. It makes a huge difference in page file performance.
...why? I've got an SSD...
My system is on a 60GB SSD, but I moved the 8GB Pagefile to a hard disk and dedicated a fast CF card to Readyboost, and the performance is just fine.
...I don't see how that improves things, over leaving both on the SSD.
Regardless, I doubt it'll provide much improvement. 4 gigs of RAM is plenty to just boot, and the Windows install I have is mostly just for games. I've recently discovered that a bootable Linux DVD actually works fine for games, so I don't think any sort of disk performance is the bottleneck to anything other than load times -- and 30 seconds instead of 10 seconds isn't that bad.
Duress code which releases false information.
Or one that destroys the drive.
Step one: Place thermite above hard drive.
Step two: Construct laptop to ignite thermite on any attempt at tampering, or when the self-destruct happens.
Step three: Summon just enough courage to reveal the wrong password when it's convincing to do so. Yes, it's going to hurt, but now they can'tget any more out of you, no matter how painful they make it. And if you were tempted to reveal the real password, realize that either way, they might keep torturing you anyway.
This could be scaled down -- rather than the laptop hard drive, it could be a small USB device which the keys never leave. I'm not sure what's known about recovering erased data from flash, but it wouldn't be hard to simply erase the block with the key on it.
Nah, they could still compromise your PC to upload the USB data later.
First, let's consider the case where we take GP literally -- it's just the bootloader on the USB drive.
So no, they can't compromise your PC, because there's only encrypted data on your PC. There's also nothing sensitive on the flash drive.
Or, take my last laptop: I had an encrypted Linux partition, and /boot partition was a USB key. I had my keys, unencrypted, on the initial ramfs. So if anyone was able to touch the USB key, ever, they could've done exactly this attack.
But I removed the USB key whenever I wasn't actively booting from it, and kept it in my pocket.
I also had a BIOS password, and the USB was the only configured boot device.
But if they'd been able to access my laptop, there's really not much they could do in the time they have access to it -- it'd have to be a physical compromise, and it seems like that'd be hard to do universally across all laptops.
This is arbitrarily limiting compatibility though. And with less compatibility between versions there's a greater risk of incompatible combinations.
It's also guaranteeing compatibility where it makes sense -- old versions of the plugin may work with new versions of the app. But new plugins for the new app shouldn't necessarily be forced to be backwards-compatible.
restarts in quick succession (e.g. installing multiple plugins) would get the bot temporarily banned from IM servers, rendering it incommunicado.
Or you provide a list of plugins, and allow the restart only once all are successfully installed. Most package managers have the concept of a trigger that happens only after all current operations are finished -- or at least, all current operations with that trigger.
Reloading into the same process, though, could be easily accomplished with a package manager -- the traditional way would be to place the new plugin script where plugin scripts are expected, and then send a HUP signal to the bot, to tell it to scan its plugin directory and load (or reload) any new (or updated) plugins.
So, it doesn't save you much, but it does save you dependencies (somewhat) and downloading. And if it was something like Rubygems, it'd actually save you those dependencies.
The advantage of doing it that way is that the distro is at least a central place where you can be sure that one stable release of an app cooperates with another stable release.
IMHO, this is a bug and should be fixed rather than mitigated with package management.
I would say it's not either-or. It is a bug, and should be fixed. But distros can at least prevent end-users from ever seeing this bug, and the easiest way to do that is to freeze packages.
It's similar, by the way, to software releases in the first place. A few programs only maintain a public SVN repository (or something similar), and do no releases. Most programs try to do releases, and the way it usually works is, you call a feature freeze, and from that point on, you may only fix bugs, not introduce features, until it's reasonably bug-free. Then you release it, and only release bugfixes for that version until the next version is completely ready.
The only real difference is that distros can treat the entire distro as a single piece of software, in that respect, much as Microsoft treats Windows as a single piece of software.
My "favorite" example of this was with Privoxy on OpenWRT. Basically, OpenWRT was lagging years behind Privoxy releases, and didn't enable gzip compression until recently.
In this case, I'd hope that someone would release a new privoxy for OpenWRT, with gzip enabled. If OpenWRT used a decent package manager, such a third-party version should be possible to integrate.
Your ideas on implementation of a better package manager sound solid. The devil, of course, is in the details, but I see no obvious problems.
I see a few.
First is performance. The initial implementation would probably build most of the OS on top of a FUSE filesystem. I don't think this would be a problem for me, personally, but many users would complain about performance. To be taken seriously, I'd have to implement the cache at least partly in kernel space.
Second is time. That is, I have none. I really want to do this right -- that is, I want to do it personally, and I want it to be done right. I don't even have time to half-ass it now.
IMHO learning is impossible unless you have at least a rough idea of what is going on. Application installation obviously isn't a trivial operation, so if the package manager makes it seem that way then it's too dumbed down.
That really depends on the application. Sometimes users have really profound insights that are born out of ignorance.
For example: There's the story of a gran
Why does God allow anybody to die? The Bible tells us that death came into the world when the first man sinned.
In other words, God likes to punish people for things they didn't do, because an ancestor did?
Besides that, God doesn't look at death the same way you do. Death is not the cessation of being, but a mere separation.
And fire is not merely death, but an incredibly painful death.
So, your god burns babies to death -- or merely burns them until they're a pile of ash, and then resurrects them to eternal life -- because of something Adam did.
And you're ok with that.
Is that something you would ever, ever do, even if you had the power to resurrect them to eternal life? Wouldn't you at least knock them out first, if you had to kill them, to be merciful about it?
God doesn't want to torture you, but it would be torture for you if he forced you to be in his presence forever.
Firstly, you cannot possibly know that. Certainly, there was a time when I didn't believe, but wanted to. At that time, if he turned out to be real, I'd certainly want to be in his presence.
Secondly, that's a false dichotomy. You're implying that the only option is to separate me from him forever for my disbelief without evidence, or force me to be near him.
He could, y'know, provide evidence, so I could make an informed decision. If he doesn't want to do that in this world, perhaps a good opportunity would be after death -- yet according to you (correct me if I'm wrong), after death I'll be cast into a lake of fire, without the opportunity to actually see a few angels and demons and change my mind.
Therefore, God allows or even sends trouble, in order for people to search again for him.
Is that the best possible way he could think of helping people search for him?
Especially considering that for some people, this has the opposite effect? Many Jews who survived the Holocaust became atheists, as they could not believe that any loving god would allow that to happen.
In our church we often hear the testimony of visiting missionaries from Third World countries, especially Africa. They testify of experiencing miracles, were lame people walk again, blind people see again and even dead people come to life again, in response to fervent prayer. You will probably tell me that their testimony is false.
Something like that. Here's a quote from David Hume:
no testimony is sufficient to establish a miracle, unless the testimony be of such a kind, that its falsehood would be more miraculous, than the fact, which it endeavors to establish.
Can you tell me honestly that these missionaries are so reliable that for them to be wrong would be more miraculous than for a dead man to rise again?
Also worth mentioning, none of those things you mentioned are limbs regenerating. There have been examples of similar things with entirely secular explanations, where lame people began to walk, where blindness was only temporary, and where someone was mistaken for dead.
Amputees are chosen as an example, because it's usually quite easy to prove that someone is missing a limb, and later, to prove that the limb is there.
Jesus enemies attributed his miracles to the devil rather than God.
And what is your reason for believing him, rather than his enemies?
That is to accurately foretell the future, especially thousands of years in advance.
It seems like what you've quoted here is a declaration of the end, not evidence of anything...
Job 26:7 He stretches out the north over the empty place, and He hung the earth on nothing.
Job 26:10 He has described a circle on the surface of the waters to the boundary of light with darkness.
These are vague enough that they might be de
I acknowledged this, and responded to it. Did you read my entire comment?
And about the technology field. Get this into the distorted reality in your head: Women don't like engineering!!
Sure, there are exceptions. But women simply like other things. Because they are women!
Bullshit. And I'm a guy.
The differences are largely cultural and stereotypes, which you're helping to promote:
Engineering as a ideal job for your life, is a male ideal, by the way!
Why must this be the case?
The best way to see what genders like, is to look at the smallest children, offer them toys for both genders, and see what they prefer to play with.
They actually tested this.
It still doesn't show a fundamental difference. For example, I bet girls like pink and boys like blue, but that's taught to them practically from birth -- in many cases, their first room is going to be full of blue for boys, or pink for girls.
The only really weird thing is, that "building" somehow is seen as better than "caring". And the weirdest thing is, that the most hard-core feminists strongly support this very male-centered view on ideals.
"Better"? I wouldn't say that...
Who was well known for caring? I can think of a few names off the top of my head -- Mother Teresa, Gandhi...
Now, who was well known for building, well, anything?
Can you name even one?
I mean, physicists come to mind much more rapidly -- Einstein, Feynman, Hawking...
If you count software, there's Linus... and RMS, but he's not really famous outside his field... and... uhm...
Maybe it's just me, but it seems very much to me that caring is seen as much better than building.
The difference is the scale, the amount of ambition. Tim Berners-Lee changed the world with his software. Gandhi changed the world with his caring... but being a stay-at-home mom isn't changing the world, and it certainly doesn't make you Gandhi.
I don't mean this as a slight against stay-at-home moms. I'm just saying, feminism used to have a point -- the appeal of wanting to create something larger than yourself is not a male-only thing. Where the hard-core feminists lost their way is in assuming that any girl who actually wants to be a stay-at-home mom has been brainwashed into that point of view -- and to prove the point, there are men who are stay-at-home dads.
Back to your point: It may very well be that women don't like engineering because they don't like engineers, not because they don't want to be one. There are many factors, but I think it's largely momentum. Engineers are seen as geeks, and find it harder to meet women in the first place. A woman shows up in the workplace, the engineers already know she's smart and they'll share some common interests, and she's the first woman they've seen in awhile...
So, she's going to get hit on a lot. Uncomfortable at best. So she'll tell her friends about it, and the stereotype of engineers being pervs is perpetuated. Eventually, she quits -- or if she doesn't, her friends never become engineers -- so "women don't like engineering" is perpetuated.
This vicious cycle continues until you either get a woman with tough enough skin to handle it, or a group of engineers who have collectively grown enough maturity to treat that woman with respect. Even here, it will take decades of things like this happening to reverse the study, to slowly bring more women into the field.
So I agree with you about the lap dancers, somewhat. But I do think that some things have to change if we want more women engineers -- and we do, if for no other reason than that it increases the number of potential engineers, meaning we'll hopefully get better ones.
The main difference is, women are more likely to complain about how this is somehow demeaning... to women.
That, and the challenge is to get them around the strippers in the first place.
Yeah, you could write new clients that make it work like twitter or IM or email. But those things already exist and work just fine.
Well, and you can extend it. And while IM and email exist, they aren't particularly integrated, nor are either of them at all integrated with a wiki...
So I guess I'm not sure what the hype is about exactly.
Well, let me put it this way...
It could turn out to be like XML, which was incredibly generic, everyone was blown away by the possibilities, and then we came back down to earth and realized that it doesn't really revolutionize anything. It's useful for what it is, but it was completely overhyped, and most places it's used, there's something better (JSON, YAML, protocol buffers, etc).
Or it could turn out to be like HTML and HTTP -- still largely misunderstood, but anyone who has a concept of what they are should understand what an impact they had.
I think it's going to be somewhere in the middle -- not nearly what HTML was, but consider: "Yeah, you could make it work like email. But that exists and works just fine." Webmail was certainly useful.
I agree, except for the part where the lap dancers are all women. Way to keep the industry a giant sausage fest...
Not that I expect women would be comfortable with any lap dancers, even males, but that would at least make it work.
I think they could, given everything else they've done lately -- though I agree it would probably be devastating for the brand.
And even if it was, they also contributed to Firefox, until they decided to start over with Chrome.
I've had it for a week or two now. Just installed it on bare metal yesterday (as opposed to a VM).
Apparently MSDN Academic Alliance gets it just as early.
My biggest issue is: eight gigs? Really?
Other than that, it does seem to be an improvement over XP, so far. And fresh installs are almost always better than upgrades.
Better yet, git push it over ssh.
I had a set of Capistrano stripts to do just that.
If something about the underlying OS changes in an update, the scripts may need to be updated.
This is also true for the app itself. The difference is, these scripts are usually managed by the distro.
Likewise, if the parent application or plugin changes then you could quite possibly need to maintain scripts for the new plugin version installing to an old parent, vice versa, old to old, and new to new.
Or you simply decide that once you update the parent application in your distro, new versions of this plugin will only work with the new parent application. So you only need "old-to-new", and that's only if the plugins remain binary-compatible.
Fixing applications so plugin systems are consistent would definitely work. It should probably be done anyway. But I'm doubtful programmers will all break plugin compatibility for that reason.
Most applications are already consistent, and the few which aren't are also not that far off. You mentioned PHP -- it really would not be difficult to make this consistent and preserve compatibility.
I suppose I once wrote an extremely modular chatbot that was designed to be fairly autonomous and remotely upgradable. Therefore, it installed, uninstalled, and hotswapped plugins as it ran. Each had mandatory settings (e.g. security level) and as such had to be mentioned in the config file. The thing is, settings were only loaded at launch, and kept internally afterwards, so a shutdown would be necessary for an external package manager to change anything.
A few incremental changes:
First, change your app so that rather than reading only one config file, it is capable of loading a config directory. This could be as simple as adding a config directive to the master config file that says "Load this directory."
Next, add a sub-config-file to each plugin. Not terribly difficult to maintain -- they probably already have examples in their README, at least.
Next, add metadata to each plugin to restart the chat server on install. Even if your package manager forces you to script it manually, it's pretty much an "/etc/init.d/mychatapp restart".
I believe this is more or less how Debian manages Apache plugins.
a shutdown would be necessary for an external package manager to change anything. This would be undesirable given the nature of the program
So how would you normally load a new plugin without shutting down?
I've seen too many repositories, download sites, and the like come and go to want to rely on them indefinitely.
Ah, so it's the centralization of download, which isn't necessary for package management, though it's usually how it's done.
And you could also look at which ones have been around the longest to get an idea of which ones are likely to continue to be around.
The lag is a fundamental part of introducing a third party to the interaction. Even if you had an obsessive package maintainer that did nothing but package stuff at 4:03 am with a 5 minute turn-around time, it's still a delay.
I've seen Gentoo add packages within hours. I can live with that, since I certainly am not doing nothing but checking for updates at 4:03 am every 5 minutes.
And again, third-party repositories can remove even this lag.
I think that's something for the application developer to fix. If an application is misbehaving a better option is to not use it and let free market forces/natural selection take place.
Perhaps, but remember that this isn't strictly natural selection -- unlike the real world, we are designing and developing these programs intelligently.
So, for example, if a program is set up really weirdly, and Ubuntu fixes it to match FHS, and the developer has more Ubuntu users than other users, the program might actually be fixed, not simply replaced. If a