コスモのチラ裏

Your awesome Tagline

97 notes

結婚て、受験や就職と違って、 時期が来れば自動的に受けるってものじゃないから、 ちゃんと意識して相手確保しないと、 いつの間にか適齢期が過ぎちゃうんだよね。

学生時代、女の子が「結婚、結婚」言うのはともかく、 男子からプロポーズされたり、 「付き合うなら結婚前提に」と言われて、 「男のくせに、もう、結婚考えるの?」とびっくりした。 でも、考えてないのは自分だけだったと、後で知った。。。

「結婚は人生の墓場」と思っており、結婚から逃げた。 その先に何もないのに。。。

「結婚は人生の墓場」と思い、結婚から逃げた。その先に何もないのに・・・。 : 鬼女速 (via otsune)

(via spring-raining)

582 notes

darylfranz:

ギズモード・ジャパン - 石油流出から自然を守るエアロゲルをペンシルバニア大が開発

ほとんど目で見ることのできないこのエアロゲル、自重の900倍近い量の油を吸収することができる99.9パーセントが空白の物質です。ゲルによって吸収された油は直接絞りだすか、燃焼させて処理することができます。これまでの除去方法である吸着マットにこのエアロゲルを上手く組み合わせれば、その作業効率は改善し、より多くの水生生物を守ることができるようになるかもしれません。

もちろん事故そのものを未然に防ぐことが一番大切ですが、被害を最小限に抑える最後の防衛線としてその活用が期待されます。

darylfranz:

ギズモード・ジャパン - 石油流出から自然を守るエアロゲルをペンシルバニア大が開発

ほとんど目で見ることのできないこのエアロゲル、自重の900倍近い量の油を吸収することができる99.9パーセントが空白の物質です。ゲルによって吸収された油は直接絞りだすか、燃焼させて処理することができます。これまでの除去方法である吸着マットにこのエアロゲルを上手く組み合わせれば、その作業効率は改善し、より多くの水生生物を守ることができるようになるかもしれません。

もちろん事故そのものを未然に防ぐことが一番大切ですが、被害を最小限に抑える最後の防衛線としてその活用が期待されます。

(via spring-raining)

70 notes

IS→打ち切り疑惑
僕は友達が少ない→順調に刊行中
かのこん→刊行ペースが激減した挙句、完結予定?の16巻が無期延期に
ゼロの使い魔→後2巻で完結の状態で作者が癌にかかって出版延期中
緋弾のアリア→順調に刊行中
けんぷファー→完結
まよチキ! →順調に刊行中
あそびにいくヨ!→2010夏より新刊が出ていない
聖剣の刀鍛冶→作者が311でPTSDにかかり、刊行ペースが激減(年4ペースが年1に)
えむえむっ!→作者死亡につき未完
陰からマモル!→2010年春より新刊がでていない


MF文庫やべぇな
MF文庫のラノベがやばいwwwwwwww病気多すぎ・・・・ : ぷよアニ速報 (via lemp3)

(via spring-raining)

3 notes

都心の私立の学生で、ラッシュ時の電車を通学に使っている男子小中高生って、 結構ショタホモやショタBBAからの痴漢被害に遭うらしいんだよね。 現在は成人したから被害に遭わなくなったけど、 実は小さい頃そういう経験があるという男性って意外といる。
男性は「男子小中高生専用車両」をどう思うんだろう?(12) - 増田まとめ (via naota344)

(via naota344)

1 note

NixOS - Declarative configuration OS (nixos.org) 236 points by wamatt 3 days ago | 75 comments | save to pocket

binarycrusader 3 days ago | link

Some of the ideas seen in NixOS can also be seen in the Image Packaging System (Atomic Upgrades, Reliable Upgrades) project: https://java.net/projects/ips/pages/Home Disclaimer: I’m also one of the IPS authors, so I agree with some of NixOS’ ideas :-) reply

davorak 3 days ago | link

I read one article and skimmed the other under “Background reading” but I could not spot what the core philosophy or mechanic of how you are producing atomic and reliable upgrades. I try to stay abreast of package systems which have the same or close feature set as nix. If you have a moment to explain the core mechanic or a reference it would be much appreciated. reply

binarycrusader 3 days ago | link

The “no scripting zone” and “no more installer magic” background posts have some of the philosophy. But really a lot of the atomic and reliable aspects are the result of integration with ZFS. When the user upgrades packages, we create a backup boot environment (clone of the root file system) and then update the packages. If anything goes wrong, the user can just reboot to the backup be. When updating the system (that is, packages that require the kernel to be reloaded/system rebooted), we create a clone of the root file system (a boot environment) and update the clone. When the update finishes, the admin can then reboot the system at their leisure. If you’d like to know more, I’ll try to answer your questions. You can email me at $myusername at gmail dot com. reply

binarycrusader 3 days ago | link

If anyone is wondering, I suspect you could take IPS and integrate with btrfs instead. The abstractions are generic and btrfs is growing the required functionality as time goes on. reply

laumars 3 days ago | link

I tried to do just this myself and Btrfs ended up corrupting my install beyond use. Thankfully this was just on a test system and I do appreciate that other people have had good success with Btrfs; but as a ZFS user for quite a few years now (since before Linux and FreeBSD ports became stable - so my file servers were originally running Solaris) and have never had an issue with the file system (in fact it’s saved me a few times), I can’t help thinking that Btrfs is still a long way off being a viable contender. What’s more, I found Btrfs’s commands to be convoluted and, at times, counter-intuitive when compared with ZFS’s. Which isn’t a deal breaker on it’s own, but it is a great shame given the opportunity they had to get it right (ie writing the entire software stack from scratch and with no legacy to worry about). This is all my personal experiences though. Others will have their own preferences and (anecdotal) evidence to support that. reply

noonespecial 3 days ago | link

We seem to be heading for a future where every application is run in a virtualized OS, configured and launched on demand. reply

PommeDeTerre 3 days ago | link

The future you describe is the distant past for many of us. We’ve been using chroot, FreeBSD jails, Solaris Containers, and similar technologies for many years now. Combined with the basic functionality of UNIX and UNIX-like systems, we can quite safely isolate users, apps and data, but without the overhead and inconvenience of heavy-weight virtualization techniques. Even then, these techniques are quite new relative to what’s been available to mainframe users for many decades. reply

gngeal 2 days ago | link

This is all too primitive. If we’re heading in the direction that the GP describes, it’s probably because some people have realized a long time ago that Alan Kay was actually making sense when he was talking about the object-based computational model as being something like “small computers all the way down”. If your application is a set of objects implementing the functionality by passing appropriate messages between those objects, and the OS is another set of objects, providing all the necessary interfaces to applications in form of capability-exposing objects, then everything is virtualized by definition. Or, in other words, in such a system, you can virtualize (in the classical sense) as much or as little as possible. Need two versions of the same library for two different applications? No problem, because each app gets its own inferface. One app needs to accesses a physical block device and another a virtual one? No problem, because each app gets its own inferface. Is the capability required by the app deployed on another machine and you want to expose it to the application transparently? No problem, because each app gets its own inferface. And if the current hardware isn’t amenable to running such systems with ease, well, that might have something to do with the fact that everything we’re running has its roots in the 1980s. The unprecedented success of the PC revolution has essentially frozen all development of substantially new systems. reply

skrebbel 3 days ago | link

We seem to be heading for a future where the only application run locally is a web browser. reply

tensor 3 days ago | link

We seem to be making the same unrealistically broad generalizations over and over, never learning from our past. reply

kryptiskt 3 days ago | link

We seem to be heading for a future where every website says “Don’t look at this, download our app!”. reply

Zigurd 2 days ago | link

There are at least three reasons that won’t happen: 1. Horses for courses: Once you get past superficial similarity, the Web isn’t a universal application runtime. It is more appropriate for some kinds of apps, such as publication media, form-filling, etc. than others, such as apps with fine-grained interactivity, apps with significant endpoint computation, etc. 2. Nobody has cracked the “write once, test everywhere” curse of multiple implementations of a standard, never mind a standard as complex, and with such a long legacy tail as Web browsers. Web app frameworks still devote a lot of code to compatibility. “Native” also means “a single vendor’s runtime.” 3. Operating systems are different, and there are varying approaches to portability. Running in a universal runtime is one approach, and it has inherent compromises. For example, Microsoft has applications for editing Office documents for Windows, Mac OS X, and for Web browsers. Which one has limitations both in terms of integrating OS features and UI conventions, and it terms of functionality? reply

TheLegace 3 days ago | link

Ya I very much doubt that. It just looks more people who barely do anything productive are on the Internet just using Youtube and Netflix. While the people who are developing say something like Youtube(or god forbid something more useful and complicated) are left to fend for themselves, because hey what do they matter. reply

foohbarbaz 3 days ago | link

This is a move in the right direction: === On NixOS, you do not need to be root to install software. In addition to the system-wide ‘profile’ (set of installed packages), all user have their own profile in which they can install packages. Nix allows multiple versions of a package to coexist, so different users can have different versions of the same package installed in their respective profiles. If two users install the same version of a package, only one copy will be built or downloaded, and Nix’s security model ensures that this is secure. Users cannot install setuid binaries. === Requirement to be administrator to install software is the root of all evils in managing OS. As far as keeping everything in a special location (/nix or whatever), this reminds me SCO OpenServer 5: they had all the files somewhere in /var; /bin, /sbin and everything else were just symlinks. It did not work all that well. reply

dEnigma 3 days ago | link

[…]the root of all evils[…] Pun intended? ;) reply

alcidesfonseca 3 days ago | link

Why did it now work all that well in SCO OpenServer 5? reply

gnoway 2 days ago | link

It was mostly in /opt, although there were also some things in /var. reply

yarou 3 days ago | link

Having installed NixOS over a year ago, I was really impressed with the package manager. It’s wonderful to be able to have multiple versions of GCC, haskell, etc side by side, so you can debug some of the reasons why your program works in one user’s version/environment but not the other’s. The actual papers are an interesting read as well. reply

laurentoget 3 days ago | link

http://audio-video.gnu.org/video/ghm2009/ghm2009-dolstra-lar… this talk by Eelco is a good introduction for hacker types. And the motivation is at the beginning of the talk. reply

GigabyteCoin 3 days ago | link

After playing around with Arch for the last few weeks, this is incredibly interesting to myself. Does anybody have any experience/testaments to post about this OS? reply

davorak 3 days ago | link

Sure, nixos is very forgiving to experiment with because you can easily rollback to a pervious configuration. Modify a library and something stops working fixing it is as simple as nix-env --rollback for a user package and nixos-rebuild --rollback if something was changed with the system configuration a restart may be needed if some systems are touched but it has not happened often and when it is needed it is specified. I enjoy how easy it is to set up different profiles with different sets of libraries/compilers for development. It has made it worth while to try out old libraries that only work on old compilers. It also made it easier for me to test against the HEAD of the complier repo for testing forward compatibility or new compiler features. Since everything is nicely encapsulated once I have an environment working on my laptop I can use nix-copy-closure to move it to another remote server. Nixops a more recent offering just renamed from charon also allows for deterministic building of ec2 instances. reply

edwintorok 3 days ago | link

If you run it in a VM (KVM/QEMU) you might need to set some CPU flags for the VM (otherwise GMP will assume your CPU has some instructions that it doesn’t actually have in the VM): https://github.com/NixOS/nixos/issues/120#issuecomment-14776… Other than that it works fairly well (in a VM), and you don’t need to wait for it to compile all the packages like with Gentoo: if the build server has a binary then it will download that. reply

jrn 3 days ago | link

took me a while to figure out. nix-env -qa * | grep “package you are looking for” nix-env -i “package” need to add different channels if you are grabbing packages from places other than nix-pkgs. I had a hard time, getting some haskell packages to work, because nixos symlinks all the binaries, and there was some encryption library dependency, hard coded in a cabal file, and it was a headache/ gave up. Eelco also provides a pathelf utility for modifiying dynamic linker in elf files, I haven’t used it. I’m on ubuntu again but I can’t remember why. Oh ya, I couldn’t get Blackberry’s SDK working on nixos. Anything that doesn’t go through nix-pkgs, will take some work. I didn’t get to the point where I was writing nix-expressions. reply

snowpalmer 2 days ago | link

The way they install multiple versions of applications and manage the dependencies reminds me of GoboLinux. I like the direction of this. Really like how they named everything though in Gobo. http://wiki.gobolinux.org/index.php?title=The_GoboLinux_File… reply

gw 2 days ago | link

I remember playing with Gobo several years back. Although renaming system directories makes it a bit more approachable to newcomers, it also makes it less language independent and less recognizable to the users who typically need to use it (sys admins and such). However, the general idea of installing things in a self-contained directory was fantastic, and I’m happy to see another operating system trying something similar. I used to use PC-BSD regularly, whose package manager also does this: http://www.pcbsd.org/en/package-management/ reply

snowpalmer 1 day ago | link

Interesting. I never knew PC-BSD did this. Been probably 10 years since I gave a BSD variant a try. reply

ztzg 3 days ago | link

For those with a penchant for parentheses, there is also GNU Guix, which just had a second alpha release: http://lists.gnu.org/archive/html/bug-guix/2013-05/msg00034…. It shares concepts and some bits with NixOS, but replaces the configuration language with Guile, an implementation of Scheme. reply

yowmamasita 3 days ago | link

This “Multi-user package management” is a really neat feature, I wonder if there are other distro’s having that. reply

aphexairlines 3 days ago | link

Multi-user and multi-aplication (different applications can depend on different versions of a shared library). Here’s another example that’s not public, and not really a distro, but… http://stackoverflow.com/questions/3380795/what-does-amazon-… reply

drdaeman 1 day ago | link

I’ve read dpkg has dpkg -i --force-not-root --root=$HOME/.local package.deb options, but I haven’t ever tried those myself. reply

lholden 3 days ago | link

GoboLinux works in a very similar manner, though I’m not sure the distro has seen any love in a few years. reply

subprotocol 3 days ago | link

Interesting, sounds like puppet/chef at the OS level. reply

jacques_chester 3 days ago | link

I’ve long suspected that something like this was the logical end point. Ever since I found myself writing a Puppet manifest that created an Upstart entry. Configuration engines have tended to emphasise bits-at-rest. “Make sure these packages are installed, that these files are present, that this is what’s in /etc”. Process management engines emphasise bits-in-flight. “Make sure Wordpress is running. Wordpress relies on PHP, nginx and MySQL”. Generally speaking, config engines assume that the bits-at-rest are correctly arranged to ensure correct runtime performance. And process management assumes that someone else has supplied the bits-at-rest which can be reified into an operational system. Configuration engines tend to stray a bit into ensuring that software is up and running (eg, cfengine polls services every 5 minutes), but stop well short of the final conclusion of process management: insertion into the init hierarchy. Why the separation? It’s historical. Each local problem was solved in isolation (broken server config / crashing server processes) and they’ve each grown at the edges towards each other. Just as ZFS collapsed several historical layers of file system tools into a single layer, it’s been long overdue for the concept of defining a model of a system’s various configurations with a detect-and-correct mechanism to be a universal framework that applies across an entire system. reply

bensummers 3 days ago | link

Solaris’ SMF and fault management framework is a very good step towards what you’re after, plus it’s mature and suitable for use in production. http://www.oracle.com/technetwork/articles/servers-storage-a… Don’t let the XML configuration put you off. I suspect they’d have used JSON if they were doing it again, but it’s from the era when XML was the default structured text based format. If you want to play with this (and IPS as mentioned above), try OmniOS: http://omnios.omniti.com/ reply

ambrop7 2 days ago | link

Is it turing complete? reply

BlueZeniX 3 days ago | link

I’ve been busy hacking together a SmartOS zone wherein the nix package manager runs. My plan is to use disnix to configure SMF services on it. reply

ambrop7 2 days ago | link

You might like a programming language I make, “NCD”. See: https://code.google.com/p/badvpn/wiki/NCD It follows a similar philosophy to Nix but for runtime management of processes and events in general. It’s really functional though. But it is a bit declarative, with the implicit backtracking, the unique feature of NCD. reply

oakaz 3 days ago | link

That’s exactly what the Linux community needs: abstractions made for people who want to save time. reply

vdm 2 days ago | link

IOW, not “the super-engineer, an idealised and imaginary extension of the Unix hackers of the era that gave birth to Unix, GNU, and finally Linux.” http://www.listbox.com/member/archive/182179/2013/05/sort/ti… reply

drivebyacct2 2 days ago | link

In my mind, it’s a much better engineered solution to have a centralized, repeatable set of configurations than to have them spread out wherever in the filesystem. reply

qu4z-2 1 day ago | link

Whenever I hear “centralized configurations” I think of the Registry and shudder. But the issue there isn’t the centralization, so it’s probably unfair. reply

brini 2 days ago | link

Interesting critique by a Debian developer: http://lists.debian.org/debian-devel/2008/12/msg01027.html reply

cwp 2 days ago | link

Not interesting at all. He doesn’t understand what nix is doing or why, and just points out all the ways that it’s different from Debian. reply

drivebyacct2 2 days ago | link

KDE4? Systemd? Experimental? Centralized, versioned configuration? Sounds very, very cool. Worthy of being installed on something around here… reply

gfxmonk 2 days ago | link

For a more application-level (rather than OS-level) approach that shares a lot of good ideas with NixOS, there’s also ZeroInstall (http://0install.net). There’s a comparison with Nix at http://0install.net/comparison.html#Nix. reply

topbanana 3 days ago | link

I’m not a Linux expert, but it seems some dependency issues won’t be resolved by this e.g. Glibc conflicts. Or would it? reply

davorak 3 days ago | link

Is there something special about glibc conflicts that goes beyond normal versioning conflicts? Package A could depending on glibc-2.13 and package b could depend on glibc-2.17. No conflicts would because by both running at the same time. reply

topbanana 3 days ago | link

I had a hell of a time installing something in Ubuntu that required a particular glibc version that was differnt to the system—wide one. Like I said, I’m not Linux expert and I probably missed a trick. I ended up using a different distro. Would this new distro have helped? reply

chubot 3 days ago | link

I think in the Nix world, you would have two or more different glibc versions at different paths. Then the applications are configured to link against the required versions. Nix has extra build metadata that calls GNU configure as far as I can tell, and that is where this knowledge would lie. So you can run two programs side by side with different glibc versions in Nix. On Ubuntu, I think this is mostly not possible, as you have found. reply

qznc 3 days ago | link

As far as i understand Nix, two users could have different glibc versions, but two programs of a single user? reply

drdaeman 1 day ago | link

I don’t see any problems here. libc is nothing special, it’s just a library that (almost) every piece of software depends upon. Two different programs may depend on two different versions of it (/nix/libc-2.10-fdsfgs/lib/libc.so.6 and /nix/libc-2.13-fgsfds/lib/libc.so.6 or even /nix/uclibc-0.9.33.1-blahblah/lib/libc.so) just fine. The only requirement is that both libc versions must support running under the current kernel¹, as you can’t have two kernels at the same time. However, it would be problematic if a single program (foo) would depend on a library (libfoo), which depends on another version of libc that foo does. I.e., dependency graph will be like foo->libc-x.xx, foo->libfoo->libc-y.yy. This would cause symbol conflict and AFAIK this can’t be solved without either rebuilding either foo or libfoo or introducing some really nasty hacks to the ELF loader (ld-linux).


¹) Google for “FATAL: kernel too old” error message to see the example of what I mean. There are patches to make newer libcs to run with relatively older kernels, though, it just requires building from source. reply

chubot 2 days ago | link

Two different versions will definitely live at different paths, since the path contains the content hash. The path doesn’t have much to do with the user name; that’s a separate issue. reply

davorak 2 days ago | link

As a single user I could run two programs utilizing different glibc versions. reply

exDM69 3 days ago | link

I had a hell of a time installing something in Ubuntu that required a particular glibc version… I have been in the same situation. But big changes in glibc that break things are very rare, most glibc version updates are backward compatible. Would this new distro have helped? Yes, but it might have required re-compiling some packages. Btw. NixOS is not such a new distro, it’s been bubbling under for years now. reply

qznc 3 days ago | link

Rhe Red Hat/Fedora package manager yum also provides a rollback mechanidm. No user installation, though. reply

davorak 3 days ago | link

Does it also provide multiple versions of the same package running side by side? That is one of the more useful features of nix to me. reply

qznc 3 days ago | link

Installing multiple versions is not the problem. The problem is configuring packages with respect to their dependencies. Nix enables per user installations and different users can use different versions of a package. What Nix cannot do (as far as i know), is using multiple versions as the same user. For example, Flash once broke due to change in the GNU libc. Can Nix use a different libc version for a specific browser plugin? reply

nbp 2 days ago | link

Nix can do that, you can easily use nix-env to create a new profile instead of using the default one stored in ~/.nix-profile . I am using multiple tool-chains stored in multiple profiles for my development process. reply

davorak 2 days ago | link

nbp is correct it is not a problem for the same user to install multiple versions of the same package.

Can Nix use a different libc version for a specific browser plugin? Are you asking about the case where the browser depends on a newer version of libc then the plugin? reply

durbatuluk 3 days ago | link

I tried this distro 2 times since I heard of this rootless package administration. I give up because of poor documentation in both situations. I would love to see this approach in arch or gentoo (without the butthurt of slots) reply

davorak 3 days ago | link

That is too bad it has worked fairly well on vmware for me. I have also enjoyed using the nix package manager on my macbook as well. The documentation can be lite on examples but it is very forgiving distribution to experiment with and I do not see to bump in to corner cases as often as I have on other linux flavors/package manager. reply

denysonique 3 days ago | link

Interesting, how is it different from Gentoo Linux? reply

vitno 3 days ago | link

check this page out to understand the underlying philosophy: http://nixos.org/nix/ reply

durbatuluk 3 days ago | link

gentoo need slot support for similar behavior reply

mbell 3 days ago | link

What linux needs is another package manager… reply

zaphar 3 days ago | link

Nix is an experimental Research OS exploring what you can do with a pure functional package manager. This is interesting. You are probably being downvoted because your comment looks like a poor attempt to cash in on the “What linux needs is another…” meme for some easy karma. But let’s take you at face value. Maybe you were serious in your assertion. While Ubuntu, Debian, Fedor, Gentoo, and many other distros use very mature, robust and all around awesome package managers I still run into issues where a package is uninstallable because of some other package that it depends on is pinned, or the wrong version, or any number of other reasons. Nix fixes exactly this problem while still maintaining many of the same benefits as the other package manager. So maybe Linux does need another package manager. Or at least it needs people willing to play around with solving issues in the current package managers in a “research” setting perhaps? reply

vidarh 3 days ago | link

Case in point: I had to upgrade some Debian VM’s with Postgres 9.0 to Wheezy with Postgres 9.1 a while ago. They were messy combinations of mostly Etch + parts of Lenny and Squeeze, as a legacy of rushed upgrades. And while upgrading Debian version by version mostly runs smoothly with apt-get, there are some very nasty gotchas: - You always need to upgrade apt and dpkg step by step, as if you’re careless, you’ll leave your system with an apt and dpkg that can’t install most of the following upgrades, including the next available version of itself due to external dependencies on packages that are only available in a format your current version of dpkg/apt does not support. You then need to downgrade. Problem is you then run into utter dependency hell. Generally the solution is to —force-all install an older version of dpkg from /var/cache/apt/archives, then update and try again. - If you’re not very careful with the apt sources when doing a Postgres upgrade, you risk having Debian install 9.1 and remove Postgres 9.0. Problem is, if it removes 9.0, you can’t run pg_upgradecluster, because that requires the old Postgres to exist and be running. Now, reverting is suddenly a big problem unless you add the Postgres teams own Debian repository. This isn’t particularly a criticism of Debian (though I dislike the fact that dpkg and apt-get have external dependencies - if there’s anything that should be built statically, it’s a package manager) - if you do things carefully, and step by step, things will work fine and you “only” need to learn a couple of rules of thumb (First, always make sure to upgrade version by version, apt-get update, apt-get install dpkg apt). These are hairy edge cases… But they’d be so much less of a problem with easy rollback and/or ability to pull in multiple versions easily. reply

davorak 3 days ago | link

I still run into issues where a package is uninstallable because of some other package that it depends on is pinned, or the wrong version, or any number of other reasons. I ran in to this problem quite often when trying out science or numerical libraries and is one of the reasons I run mostly on nixos now. reply

[deleted]

saosebastiao 3 days ago | link

Why doesn’t it need any more fragmentation? Your argument is begging the question. Personally I think people are better off with 50 kinds of spaghetti sauce. reply

v13inc 3 days ago | link

I think this comment from jacques_chester [1] does an excellent job at explaining why it is important to break free from this mindset periodically. It is all about busting out of local maxima in the efficiency of our tools. [1] https://news.ycombinator.com/item?id=5727876 reply

jacques_chester 3 days ago | link

Local maxima, exactly. We often lose sight of how and why we are at a particular maxima and assume that the current layering is the only acceptable layering. But sometimes it’s just accidents, or was just the shortest path to a working system, or lots of little local solutions that agglomerated into larger global solutions. Every once in a while punching through the old layers is useful. Not always. Sometimes. Having a sense of history makes this easier … and harder. Sometimes the outcome is so stunningly obviously better that everyone slaps their foreheads and wonders how it could have been any other way. Other times … well, other times we all spend our workdays arguing about it on HN. reply

pekk 3 days ago | link

Improve in what way? This puts any design change off the table forever. I don’t see anything wrong with a rethink, as long as it’s motivated. Maybe the motivation has not been well-stated - but maybe you haven’t made it any clearer that dpkg or rpm are the optimal package managers (barring a few little ‘improvement’ patches here or there). Just blasting the project in the most generic terms is avoiding the necessary thinking about what the goals should be and what are good ways of achieving them. reply

smilekzs 3 days ago | link

It seems that people have good enough reasons to do away with fragmentation. And this doesn’t sound like just a package manager. It’s also taking care of configurations. That said, I’d love to see this integrated into Arch some day. reply

noonespecial 3 days ago | link

What linux needs is a better package manager. I’m not convinced that the entire solution space has been explored yet so I welcome all newcomers. reply

banachtarski 3 days ago | link

And fewer asshats. reply

NixOS - Declarative configuration OS | Hacker News (via bleuscr)

(via bleuscr)

2,113 notes

仕事が無くて、麻薬作って生計立ててる地域では、
「蕎麦作って売りなしゃい。買うたるから。」という事業をやってる。
結果、若者は仕事を得て、世界と日本では麻薬の流通が減る。

また東南アジアの海沿街で、失業者が溢れている所では
「小魚を乾燥させて袋に詰めんしゃい。買うたるから。」とやって、
若者は漁を続けることが出来て、若い女性が職場を得た。
んでその付近には学校や病院も出来て、慢性的な失業と犯罪が解消された。
(そこの小魚を袋に詰めてる女性は、その魚をどうするのか知らないそうだ。
日本で出汁に使ったり、そのまま食べると知って驚いていた。)

などなど、日本人主導の日本への輸出事業開拓で
荒れずに済んでいる地域はたくさんある。
こういう国際貢献もたくさんしてることを、あまり報道しないね。

当然上記のような事業は、初期段階で日本側の大赤字になるけど
「人のため」にやってる面があるから続く。
もちろん思う通りにはいってない事もあるけれど。
よくアメリカとかが日本市場の閉鎖性云々ほざくけど
利益追求の都合だけで、現地人を道具としてしか見ないアメに言われたかないよね。

【文化】ジャポニスム【世界の中の日本】スレのまとめ 食う物・食わざる物と一神教・多神教(part11スレ) (via mcsgsym) (via quote-over100notes-jp) (via hikutuo) (via pocomoco) (via highspeedturbine) (via next2501) (via mysmn) (via moja-moja) (via fumi-tano) (via carbondoubt) (via syabuichi) (via spirallife) (via homest) (via deli-hell-me) (via text-man) (via k32ru) (via sakito) (via cametan-001)

1,302 notes

貧乏人たちの共通点

貧乏人は他人に厳しい

貧乏人はとにかく人に親切でない。この程度の親切ならと思えるようなこともしない。金銭的な面だけじゃなくて、「世話になっている人に対してこの程度の手間なのに」と驚くようなことすら断ったり。

これはおそらく、親切にして得られる信用の費用効果計算できず、自分のメンツを重視するからだと思う。とあるニートにお願いを断られたこと(だいたいニート個人の作業として30分もかからないこと)で、私は落胆し、数万円くらいのバイトを紹介するのをやめたことがある。数万円は親に小遣いをもらっているニートにしてはたいしたことがない数字かもしれないが、それでも30分くらいの手間で、数万円のバイトを紹介してもらえるなら、悪くない投資のはずだが。

貧乏人は無駄遣いをする

貧乏人はとにかく無駄遣いをする。100円で買えるものが150円で売っていても、かまわずに払う。お金持っていないのにいいのか、と私が思うようなことでも、無駄ものに考えなしにお金を払う

貧乏人はお金を使わない

貧乏人はお金を使わない。無駄遣いはするが、お金は使わない。

うまくいえないが、お金を使う勘所を意識していないのではないか自分のところに貯めておくべきお金ギャンブルをし、堅実な貯金で将来的に自分お金はいることに気が回らない。

いわゆる投資もそうだが、若い人やこれからの人を支援したりすることには徹底して時間お金を惜しむ。そのことでよりお金が回ることを知らないからだ。

貧乏人は周りを大切にしない

貧乏人は周りを大切にしない。無駄遣いばかりする代わりに、友人に贈り物はしないし、私のような社会人居酒屋でちょっと多めに払ったりは決してしない。

これは、その行為無駄遣いだと思ってるのかな、と思ってたのだけど、そこまで合理的ではない。ただ周りの好きな人間を大切にしなくてもかまわないという気持ちのようだ。

貧乏人は勉強しない

貧乏人は勉強をしない。とにかく本を読まない。講演を聴かない。人から教えてもらわない。

勉強したことが無駄にならないことをわかっていないからかもしれない。

貧乏人は聴くより語る

貧乏人は聴くより語る。人にたいして自慢話をしたりはしょっちゅうだ。そして人の話を聞こうとしない。

人の話を聴くメリットより、自分の話をするメリットのほうがでかいと思っているわけだ。ペラペラ自分の話ばっかりする貧乏人は多い。

貧乏人は挑戦しない

貧乏人は挑戦をしない。やったことないことや、苦手なことをあえてやってみようとしない。たとえば、ゲームセンターなんかにいかない人たちだが、たまたまいったら流行っているゲームをやってみようなどということはない。普通の人が面倒になって見てるだけだったりするのに加わるだけで、積極的に挑戦をしようと思わないことが多い。

失敗するリスクの低さと、経験のリターンの大きさを知らないのだろう。

貧乏人は短期的にポジティブ、長期的にネガティブである

貧乏人は短期的にポジティブ、長期的にネガティブである。よく貧乏人はネガティブな人が多いと言われるが、実際には、そうでもない。短期的には楽観的だったり不安に思わなかったりすることが多い。避けられる失敗をなるべく避けようとする気持ちが少ない。

一方で、将来的に自分がどうなるか、などに関しては驚くほどネガティブである。長期的に悲観になっても無駄だということを知らない。逆に、短期的に「まあいいか」と楽観的になると、のちのち悪いことが起きるのを知らないので、目の前のことに対しては真剣に考えない。

貧乏人に大量に触れて初めて気づいた8の共通点 (via rulebook)

(via cametan-001)

1,553 notes

アメリカで昨年出版された「子育ての衝撃」という本が話題になっている。本書で最も驚くべきくだりの一つは、人種差別にかかわる部分だ。著者の ポー・ブロンソンらの調査によれば、子供たちに人種の多様性を教えようとする私たちの方針は、根本から間違っているという。

 私たちはこんなふうに考えがちだ。現代の社会には、もう露骨な人種差別はほとんどない。いまや子供たちは、多様な人種が入り交じる環境の中で育っ ている。彼らはそうした環境の中で、他の人種とうまくつきあっていく方法を自然に学んでいくだろう。だから私たちは子供たちに対して、人種について、皮膚 の色について語るべきではない。わざわざ寝た子を起こすことはない、と。

 しかしブロンソンらの調査結果は、私たちの楽観に冷水を浴びせかけるものだった。

 事実はこうだ。白人の高校生で、他の人種の親友を持つものはわずか8%。多くの人種が通う学校の生徒たちほど、人種間の交流は少ない。白人の親の 75%は、子供たちと人種についてほとんど語り合わない。小学3年生以上になると、人種への偏見を変えるのは困難になるが、多くの両親がこの話題について 話しても大丈夫と考えるのは、その後になってからである。

 要するに、大人が人種についての話題を避けたままでいると、多くの子供はのびのびと立派な差別主義者になってしまう、ということだ。

時代の風:「健全育成」のために=精神科医・斎藤環 - 毎日jp(毎日新聞) (via katoyuu) (via abuf) (via send)
2010-04-11 (via gkojay) (via vmconverter) (via hexe) (via yaruo) (via sytoh) (via send) (via susue) (via gotouyuuki-text) (via n0mzk) (via miminashi) (via otsune) (via motomocomo) (via mitaimon) (via nanama) (via nnzai) (via ibi-s) (via sakito) (via cametan-001)