Vimeo does have a ban on commercial use, unless you purchase their new(ish) Vimeo Pro. I don't think it has good ad platform, making it a no-go unfortunately...
Don't worry, I've been pushing for it and AFAIK someone somewhere is maybe sort of hopefully looking into it... right now I can't even see the videos since Flash blows on 64-bit GNU. And it's evil (sorry, running a huge proprietary app that has had a storied history of remotely exploitable security vulnerabilities is not something I'm comfortable with).
I'll invite some furries over to make a batch of romulan ale on my 10k BTU burner with an arduino attached, and then sell the results on the silk road for Btc?
Well, that's what I've been doing... five or six pounds of honey, five gallons of cider, some fruit extract, mix it all up... ok, this is the gravity...
It still feels wrong that I'm not using science to control the entire process (eh, I started off brewing beer...)
Interesting -- I've gotten a bit into Cyser making, and noticed the dearth of software for that too. The big thing for me has been dealing with e.g. apple cider -- it contributes gravity and volume, and none of the brewing software I've found handles doing math for ingredients like that.
Heating honey damages its flavor, and I think (don't hold me to this part) can cause a bit of haze in the final product. Think of honey flavor like you might aroma hops -- the longer you heat it the more aromatics evaporate... do it long enough and you end up with sugar that happens to be bee puke.
Instead... you can do what wine makers do (since they rarely boil anything): dose it with a bit of sulfite to knock out any native yeast and bacteria, and then pitch brewing yeast after letting it out gas a bit (read: let it sit overnight). The yeast we use for brewing is basically sulfur tolerant and so, between the natives being supressed or dead and pitching a few hundred billion of 'em, the brewing yeast dominates.
The GP, however, appears to like fermenting a bit on the wild side and letting some of those natural yeasts and bacteria compete with the yeast he's throwing into the must... different strokes for different folks.
The issue was its poor handling of randr change events... e.g. removing or attaching a new display, which I do 5 or 6 times per day (restarting WM each time for that got old very quickly).
Since Window Maker has had pretty bad multi-display support, when I got a new laptop a summer or two ago I looked for replacements and discovered... Sawfish is alive too. I'm using it now with xfce-panel and gnome-session (2.x since 3.x hates me) and it's pretty tolerable (supports all of the new window hints and session management stuff... giving me something that's almost as reliable as what I had with Window Maker a decade ago). I really, really miss the dockapps though... the network and cpu monitors available nowadays blow and I've never really gotten over now having a dock app to control my music player ("media keys" get the job done but you get used to doing things a certain way when you've done them that way for a decade and all).
xcompmgr was always just the demo/reference compositor... IIRC it had (still has?) memory leaks... cairo-compmgr almost works but for whatever reasons goes out to lunch whenever changing display settings (I might have a laptop and external monitor so that makes it really, really unusable for me).
Unfortunately things like Expose can't be implemented in an external compositor now (at least not in a flashy or particularly usable way)-- there's no way for the window manager to say "hey can you do this fancy animation crap for me". AFAICT there is only a window property that communicates the translucency level of a window available. The same goes for fancy iconization effects, graying out unfocused windows, wobbly dragging, etc.
And so every window manager ends up having to implement its own effects using its own internal protocol... it's a hard problem figuring out the needed common ground (especially when GNOME and KWin both appear to be actively divorcing themselves from X11). I've always wondered how hard it would be to at least make Compiz a library that other window managers could integrate (some construction needed) to gain compositing and effects... but I'd rather whine about how CLIM had a transformation and frame management protocol in 1995 that could do all of this without radical replumbing like X11 does;)
In a more perfect world there would be a protocol for compositors and window managers to communicate so you could implement such things in a single place instead of reimplementing it umpteen times in each environment:(
The construction cost of the pair of AP1000 works out to $6.36 per watt (ish)... the only way to get a cost that high is if the plant never actually goes online. In reality, the plant will operate for 40-60 years. The world nuclear association has a reasonable writeup of the actual costs of current reactors, and the estimated costs of new ones. It's looking like it'll be around 10 cents per killowatt.
This is true. If you oppose nuclear, a coal plant will be built in its place, which is far, far more dirty and dangerous.
Actually, nowadays it's more likely that a natural gas power plant will be built since the regulations around coal are pretty restrictive. Cleaner than coal... but still pumping obscene amounts of CO_2 into the atmosphere.
Oi, the tagging/section system decided to use science instead of idle despite being tagged idle before science and... when in doubt, I like to blame Slashcode for my relationship problems.
It's mostly a pain in the ass to wait a week for the disc to get there so that I can circumvent their asinine DRM scheme with a trivial process. Why won't they just sell me the files in the first place?
All of those services are only available if you are willing to accept proprietary software and give up ownership of your data (even amazon prime for all of its good ideas still relies on Amazon remaining in business and offering that service in perpetuity).
Why isn't there something akin to the many DRM-free music services? I can already do the PITA that is waiting for a physical DVD and rip that trivially.
There are a few problems with functional programming languages
that have prevented their true adoption anywhere.
1. Limited paradigms - I always prefer languages that let me
write my code the way I want, a la C++, than a language that
requires a strict paradigm from academia like Lisp. If I want
to use the inherent hardware property based side effects of
certain code structures, let me. Programming languages =/=
mothers.
Common Lisp (and Scheme, even more so, although the community is
more oriented toward impure functional style) enforces no fixed
paradigm. It can be used functionally (conses
happen to be a pretty good data structure for functional
algorithms), but is more often used in an object-oriented
manner. It was even one of the first OO languages, and AFAIK
the first to implement multiple
dispatch. It even has a powerful
imperative operators.
3. Most functional languages except Ocaml are like Ruby and Python
in that they have tremendous performance overhead. For a consumer
application, that overhead usually doesnt impede adoption (its more
like the software is poorly written than the applications environment
is too inefficient). But when talking about server programming the
costs of running something under Ruby vs C are astronomical, and the
same problem arises with functional programming. It might not hurt
the consumer that the Python implementation of their music player
consuming 30% more clock cycles than the exact same program written in
C, but it does cause huge scaling issues with popular resources like
Twitter.
4. In extension of 3, functional programming is getting away from
how the hardware actually works. It is good for a novice that doesnt
want to get into the details of pointers and caching and disk IO, but
professionals should enter the game knowing how the underlying system
runs and that making tradeoffs for readability by someone who doesnt
know the language anyway vs performance benefits falls to the wayside.
Developer time is important, but when you factor in the massive
overhead trying to get 20+ year professional developers in C to try to
think functionally you are never justifying the upfront cost of using
the languages.
Languages like SML and OCaml are actually more optimizable
than C. Thanks to providing more type information &c they can
take advantage of fancy whole program optimization and whatnot.
The "way hardware works" is an artifact of C being the dominant
language. There's no reason hardware couldn't (and it has before)
have GC assistance, type checking, capabilities, etc. It's really
not appropriate and scalable to view the computer as something
that flips bits around a gigantic linear array... it was
reasonable to deal with that when you had 4000 words, but not when
you have 400000000 words.
Software is nice because you can abstract! Writing programs to a
model of an infinite store that Just Works (tm) is beneficial to
everyone -- it frees source code from a particular hardware
implementation, is easier to reason with, and separates the
concern of hardware resource management.
It could be argued that the problem lies with hard disks and not the applications. SSDs are nice because you aren't forced to artificially contort data access to fit the slow-seek/fast-linear-throughput model of magnetic hard disks. Removing an arbitrary restriction on program style is a good thing.
A counterargument would be that if we had a minimally structured container format that everyone used you could save a lot of time. Untyped binary blobs work as a lowest common denominator format, but they can be a huge pain to work with. Personally I wish we'd move to a more structured model for data (the relational people have a point) -- I find it far more pleasant to e.g. write an SQL query than to hack together a script to munge data from five different file formats to get the output I need.
But, of course, libc provides untyped blob I/O and so that's what everyone uses. It's kind of hard to break from 40 years of code no matter the benefits.
Slashdot Mirror
Vimeo does have a ban on commercial use, unless you purchase their new(ish) Vimeo Pro. I don't think it has good ad platform, making it a no-go unfortunately...
Don't worry, I've been pushing for it and AFAIK someone somewhere is maybe sort of hopefully looking into it... right now I can't even see the videos since Flash blows on 64-bit GNU. And it's evil (sorry, running a huge proprietary app that has had a storied history of remotely exploitable security vulnerabilities is not something I'm comfortable with).
I'll invite some furries over to make a batch of romulan ale on my 10k BTU burner with an arduino attached, and then sell the results on the silk road for Btc?
You can mix-and-match components ... right now I'm running the gnome2 desktop with sawfish and xfce-panel.
I find spelling unpossile diffikult sometimes.
Well, that's what I've been doing ... five or six pounds of honey, five gallons of cider, some fruit extract, mix it all up ... ok, this is the gravity...
It still feels wrong that I'm not using science to control the entire process (eh, I started off brewing beer...)
Interesting -- I've gotten a bit into Cyser making, and noticed the dearth of software for that too. The big thing for me has been dealing with e.g. apple cider -- it contributes gravity and volume, and none of the brewing software I've found handles doing math for ingredients like that.
Heating honey damages its flavor, and I think (don't hold me to this part) can cause a bit of haze in the final product. Think of honey flavor like you might aroma hops -- the longer you heat it the more aromatics evaporate... do it long enough and you end up with sugar that happens to be bee puke.
Instead ... you can do what wine makers do (since they rarely boil anything): dose it with a bit of sulfite to knock out any native yeast and bacteria, and then pitch brewing yeast after letting it out gas a bit (read: let it sit overnight). The yeast we use for brewing is basically sulfur tolerant and so, between the natives being supressed or dead and pitching a few hundred billion of 'em, the brewing yeast dominates.
The GP, however, appears to like fermenting a bit on the wild side and letting some of those natural yeasts and bacteria compete with the yeast he's throwing into the must... different strokes for different folks.
Well, the article implies that he hasn't implemented xhost security yet so it's kind of a moot point right now :)
Note this is not X.org, but a new implementation of an X11 server in Java. Which is pretty neat if you ask me.
Guilty on both counts ;)
In casual conversation, I refer to the OS as "GNU" -- If it's just Android ... you must acquit.
The issue was its poor handling of randr change events ... e.g. removing or attaching a new display, which I do 5 or 6 times per day (restarting WM each time for that got old very quickly).
Since Window Maker has had pretty bad multi-display support, when I got a new laptop a summer or two ago I looked for replacements and discovered ... Sawfish is alive too. I'm using it now with xfce-panel and gnome-session (2.x since 3.x hates me) and it's pretty tolerable (supports all of the new window hints and session management stuff ... giving me something that's almost as reliable as what I had with Window Maker a decade ago). I really, really miss the dockapps though... the network and cpu monitors available nowadays blow and I've never really gotten over now having a dock app to control my music player ("media keys" get the job done but you get used to doing things a certain way when you've done them that way for a decade and all).
xcompmgr was always just the demo/reference compositor... IIRC it had (still has?) memory leaks... cairo-compmgr almost works but for whatever reasons goes out to lunch whenever changing display settings (I might have a laptop and external monitor so that makes it really, really unusable for me).
Unfortunately things like Expose can't be implemented in an external compositor now (at least not in a flashy or particularly usable way)-- there's no way for the window manager to say "hey can you do this fancy animation crap for me". AFAICT there is only a window property that communicates the translucency level of a window available. The same goes for fancy iconization effects, graying out unfocused windows, wobbly dragging, etc.
And so every window manager ends up having to implement its own effects using its own internal protocol... it's a hard problem figuring out the needed common ground (especially when GNOME and KWin both appear to be actively divorcing themselves from X11). I've always wondered how hard it would be to at least make Compiz a library that other window managers could integrate (some construction needed) to gain compositing and effects... but I'd rather whine about how CLIM had a transformation and frame management protocol in 1995 that could do all of this without radical replumbing like X11 does ;)
In a more perfect world there would be a protocol for compositors and window managers to communicate so you could implement such things in a single place instead of reimplementing it umpteen times in each environment :(
Oops, I saw kWh and not kW (and forgot the h after the kW in my post, confused enough yet?). My comments can be disregarded until I learn to read.
The construction cost of the pair of AP1000 works out to $6.36 per watt (ish)... the only way to get a cost that high is if the plant never actually goes online. In reality, the plant will operate for 40-60 years. The world nuclear association has a reasonable writeup of the actual costs of current reactors, and the estimated costs of new ones. It's looking like it'll be around 10 cents per killowatt.
This is true. If you oppose nuclear, a coal plant will be built in its place, which is far, far more dirty and dangerous.
Actually, nowadays it's more likely that a natural gas power plant will be built since the regulations around coal are pretty restrictive. Cleaner than coal ... but still pumping obscene amounts of CO_2 into the atmosphere.
PRISM / IFR designs in general (and Molten salt breeders, in theory) turn that "waste" into enough fuel to supply the earth ... forever, assuming we build pyroprocessing facilities (PUREX generates a lot of waste ... no good).
Oi, the tagging/section system decided to use science instead of idle despite being tagged idle before science and ... when in doubt, I like to blame Slashcode for my relationship problems.
It's mostly a pain in the ass to wait a week for the disc to get there so that I can circumvent their asinine DRM scheme with a trivial process. Why won't they just sell me the files in the first place?
All of those services are only available if you are willing to accept proprietary software and give up ownership of your data (even amazon prime for all of its good ideas still relies on Amazon remaining in business and offering that service in perpetuity).
Why isn't there something akin to the many DRM-free music services? I can already do the PITA that is waiting for a physical DVD and rip that trivially.
There are a few problems with functional programming languages that have prevented their true adoption anywhere.
1. Limited paradigms - I always prefer languages that let me write my code the way I want, a la C++, than a language that requires a strict paradigm from academia like Lisp. If I want to use the inherent hardware property based side effects of certain code structures, let me. Programming languages =/= mothers.
Common Lisp (and Scheme, even more so, although the community is more oriented toward impure functional style) enforces no fixed paradigm. It can be used functionally (conses happen to be a pretty good data structure for functional algorithms), but is more often used in an object-oriented manner. It was even one of the first OO languages, and AFAIK the first to implement multiple dispatch. It even has a powerful imperative operators.
Thanks to macros and the metaobject protocol you can even add new paradigms to the language. Paternalistic, Lisp is not.
3. Most functional languages except Ocaml are like Ruby and Python in that they have tremendous performance overhead. For a consumer application, that overhead usually doesnt impede adoption (its more like the software is poorly written than the applications environment is too inefficient). But when talking about server programming the costs of running something under Ruby vs C are astronomical, and the same problem arises with functional programming. It might not hurt the consumer that the Python implementation of their music player consuming 30% more clock cycles than the exact same program written in C, but it does cause huge scaling issues with popular resources like Twitter.
4. In extension of 3, functional programming is getting away from how the hardware actually works. It is good for a novice that doesnt want to get into the details of pointers and caching and disk IO, but professionals should enter the game knowing how the underlying system runs and that making tradeoffs for readability by someone who doesnt know the language anyway vs performance benefits falls to the wayside. Developer time is important, but when you factor in the massive overhead trying to get 20+ year professional developers in C to try to think functionally you are never justifying the upfront cost of using the languages.
Languages like SML and OCaml are actually more optimizable than C. Thanks to providing more type information &c they can take advantage of fancy whole program optimization and whatnot.
The "way hardware works" is an artifact of C being the dominant language. There's no reason hardware couldn't (and it has before) have GC assistance, type checking, capabilities, etc. It's really not appropriate and scalable to view the computer as something that flips bits around a gigantic linear array... it was reasonable to deal with that when you had 4000 words, but not when you have 400000000 words.
Software is nice because you can abstract! Writing programs to a model of an infinite store that Just Works (tm) is beneficial to everyone -- it frees source code from a particular hardware implementation, is easier to reason with, and separates the concern of hardware resource management.
It could be argued that the problem lies with hard disks and not the applications. SSDs are nice because you aren't forced to artificially contort data access to fit the slow-seek/fast-linear-throughput model of magnetic hard disks. Removing an arbitrary restriction on program style is a good thing.
Ask and ye shall sort-of receive.
A counterargument would be that if we had a minimally structured container format that everyone used you could save a lot of time. Untyped binary blobs work as a lowest common denominator format, but they can be a huge pain to work with. Personally I wish we'd move to a more structured model for data (the relational people have a point) -- I find it far more pleasant to e.g. write an SQL query than to hack together a script to munge data from five different file formats to get the output I need.
But, of course, libc provides untyped blob I/O and so that's what everyone uses. It's kind of hard to break from 40 years of code no matter the benefits.