partiallydisassembled.net

Wattometer

2007-03-10 13:20:13

I've managed to get suspend-to-RAM working on my desktop. Main difficulties were * nForce 4 ethernet wouldn't restart after resuming, needed to compile as a module and unload before suspending * Clock is completely borked on resume, have to stop and start ntpdate to fix. * I was editing the wrong config file for about 2 days, which made things not get better when they should've. Otherwise no problem with X, alsa or beryll. Net services (sshd and squid) naturally also have to be restarted after resume. My BIOS has options for keyboard or mouse to wakeup, but neither work, I have to use the power button. Takes around 4 seconds to get from suspended to fully up. Borrowed a Watt-meter from a guy at uni, and ran around the house with it today. Only plugged it into wall sockets, so each reading includes the "off" state of all other appliances plugged into the same socket (all readings in Watts). In the study (desktop, two LCD monitors, printer and valve amplifier): Everything off 8.5 Amplifier on 24 (amplifier off for remaining tests) Printer warming up 270 Printer idle 15 (printer off for remaining tests) Monitors on standby 8.8 PC Starting up 195 Idle in X11/Beryll 175 100% CPU 210 (while True: pass) glxgears 230 neverball 200 tuxracer 190 Suspended (to RAM) 13.5 Music setup (digital piano, small amp): Everything off 0 Amp only 5 Piano only 5 8W fluorescent lamp 8 TV setup (LCD TV, DVB-T, CD, DVD, VCR, transistor amplifier): Everything off 15.9 CD playing 36.7 (amplifier, CD player) DVB-T radio 49 (amplifier, DVB-T) DVB-T TV 154.5 (amplifier, DVB-T, TV) DVD playing 126 (amplifier, TV, DVD) VCR playing 145 (amplifier, TV, VCR) Old CRT TV: Off 0 Standby 5.5 On 75 I'm charged 13.05 cents per kWh, so having the computer suspended instead of idling is $14/year instead of $200/year. Not bad! Oh yeah, I should probably watch less TV too ;-)

comment

Not news

link comment

2007-02-28 00:05:48

Something I didn't know about Dick Cheney: he generates anti-news wherever he goes. What's anti-news? Well, it's all about what didn't happen during the day: First he gave no information about a possible strike on Iran. Then, he assured us that our hypothetical puny actions will have no effect on the US-Australia alliance (read: hierarchy). On his way home, his plane did not suffer a mechanical breakdown of any significance, and made a scheduled stopover. Today we hear the headline anti-news that of the 18 people who died in a suicide bomb attack in Afghanistan, Cheney was safe and not near the blast. Given all the things that we are told did not happen, can we subtract these from the set of infinite possibilities to deduce what really happened this week?

comment

Clean tax

link comment

2007-02-12 13:40:32

I propose a carbon tax. Any politician, be they Liberal, Labour, Republican or Democrat, who mentions "clean coal" without a clarifying adjective such as "poisonous", "polluting", "environmentally unsound", "unproven" or "non-existant" must pay a tax. The amount they pay must be in proportion to the number of voters they mislead, and to the amount of "real" carbon combusted by said voters who gain false hope that such a technology will save their children. It shouldn't take a left-wing liberal pinko to see that pumping a poisonous gas into the ground or ocean is a somewhat risky environmental move, considering how well we went with merely dispersing it into the atmosphere. Thankfully Howard has clarified his position: he will not support any emissions scheme "that burdens our industries whilst allowing others that are less efficient and greater polluters to get competitive advantage." Thank goodness!

comment

Schema-less database

link comment

2007-01-28 19:17:39

This is a half-thought-out idea. If it's been done before, please tell me so I can see how it ends ;-) The problem with relational (and object) databases is that the schema is relatively fixed. The reasoning is that business processes change far more frequently than storage needs. I've always thought that this is backwards, and that altering table schemas is the biggest, hardest, most common refactor to apply to an application. Forget everything you know about relational (and object) storage. The world consists of *items*, which have *properties* and optional *values*. Nothing groundbreaking here. A property's name is in fact another item (allowing for metadata on properties), as is the optional value. A relational mapping might look like: TABLE items item_id (PK) data (string) TABLE mappings mapping_id (PK) item (FK -> items.item_id) property (FK -> items.item_id) value (FK -> items.item_id or NULL) A book might be an item with properties: 'book' (no value, just tells us that it's a book) 'title' (data of value is string, or properties of value could break into subtitle, etc) 'author' (data of value might be unused; value has properties like 'name', 'address') Some operations you can perform on a populated database: # set of all items I() = SELECT item_id FROM items I, mappings m WHERE I.item_id = m.item # set of all items with an 'author' property I(author) = SELECT I.item_id FROM items I, mappings m, items P WHERE I.item_id = m.item AND P.item_id = m.property AND P.data = 'author' # set of all items where 'author' = 'Alice' I(author='Alice') = SELECT I.item_id FROM items I, mappings m, items P, items V WHERE I.item_id = m.item AND P.item_id = m.property AND V.item_id = m.value AND P.data = 'author' AND V.data = 'Alice' # set of all items where author's first name is 'Alice' I(author.firstname='Alice') = SELECT I.item_id FROM items I1, mappings m1, items P1, items V1, mappings m2, items P2, items V2 WHERE I1.item_id = m1.item AND P1.item_id = m1.property AND V1.item_id = m1.value AND P1.data = 'author' AND V1.item_id = m2.item AND P2.item_id = m2.property AND V2.item_id = m2.value AND P2.data = 'first' AND V2.data = 'Alice' # set of values of 'title' property on all items I().title # titles of all books by Alice I(author='Alice').title # books I have purchased I(purchaser='Alex') # other books by authors I have purchased I(author=I(purchaser='Alex').author) # other purchasers of books by authors I have purchased I(author=I(purchaser='Alex').author).purchaser # books that were purchased by people who've bought a book by an author # of a book I've purchased (recommendations) I(purchaser= I(author= I(purchaser='Alex').author ).purchaser) Properties can also be treated as user-added tags... # set of all properties P() = SELECT item_id FROM items P, mappings m WHERE P.item_id = m.property # set of all properties defined on all items (excludes orphaned # properties) P(I()) # set of all properties defined on items that have a 'howto' property # (other tags of howtos) P(I(howto)) # set of items that have at least one of the properties defined on the set # of items that have a 'howto' property # (items related to howtos by their tags -- e.g. catches items tagged # "howto", "guide", "faq", "manual") I(P(I(howto))) Metadata on properties: # Set of all properties of type 'int' I(P(type='int')) # Properties that are actually tags P(tag) # More thought on notation needed here.. # Meta-properties can form property hierarchies. Some consequences: * There is no schema defined in the database. Applications define their own schema and redefine it at any time. * Applications can share data within a database, so long as their are no name conflicts. "Well-behaved" applications could add an "application" property to items and meta-property to properties to effectively isolate the items and properties they are responsible for. * Properties and meta-properties make generic database explorers/editors very feasible. Related-tag queries shown above can be used to suggest properties to add to items. * "Everything is a set" may be limiting, but I suspect not. * Store information in "data" attribute or in separate properties is a confusing point, similar to XML element/attribute problem. Can't see any solution -- convention would be that if an item has properties, 'data' is a summary (a sort of __repr__). * The generated SQL queries get quite large very quickly. Can be simplified if meta-properties are not supported (3-table model). Or, perhaps a relational backend should not be used. Some possible extensions: * History / version tracking easily applied to Items table. Notation could become quite a bit more complex though. * Explicit typing can also be applied to the 'data' property of Items table. A convention of appending type name to property name would simplify notation: I(user.birthday_date=today) * Explicit user / access controls. Could also be applied using properties, but limiting access to the acl properties is problematic.

Richard writes:

Interesting idea. I'd have thought a big consequence would be speed due to the lack of indexes. I(author) isn't valid Python (unless author is actually a declared variable but that's not what you mean in your example). You could use I(author=all) (where "all" is the builtin) The Roundup "anydbm" hyperdb backend is actually kinda similar to this except that it does have a schema. It doesn't really need one (the schema can change on a whim with no impact on the data stored in anydbm) except that the schema enforces property types and also allows many-to-many relationships (though there's no reason your proposal couldn't hande M2M). Since it also lets you define link and key properties you get indexes.

Andy Todd writes:

See RDF ;-) The problems with this approach are; - How do you summarise information in your database (counts, sums and other calculations)? - How do you manage change? If you want to change a database schema it is (as you rightly point out) a hard job and has to be applied to all of the instances (rows) of a class (table) or none. With this hybrid approach when you want to change something you can have instances of nominally the same class with different attributes, which can confuse. - Speed. But Richard's got that covered.

Alex writes:

Cool, thanks for the feedback. At this stage I'm just curious if I'm touching on prior art (scouting for PhD ideas). Had thought about RDF, but I think this is sufficiently different to warrant its own investigation. Specifically, I'm _not_ encoding any information about the type of relationship, or trying to infer anything about relationships, within the DB, which is pretty much the point of RDF (AFAICT). Re: notation errors: was not intended to look Pythonic, it just happened that way ;-) Re: speed: firstly, I'm not yet saying a relational backend is ideal, and there may be ways to index and store data in this format more efficiently. Even with relational, the "data" field can be indexed (either for short strings, i.e. property names only, or full-text search), as can all the id fields, so I can't see that each join or select is going to be any slower than a relational db, besides having more joins. Since everything's a set, aggregates are easy (both in notation and to compute): number_of_books = count(I(book)) Ok, it's obviously not fully thought through yet. I suspect I can get around the change issue completely though. No schema, not even implicit. The application defines and uses the properties and items it wants to. If an item doesn't conform (checked on access), then it's not returned in the query, so (to the application) doesn't exist. Perhaps namespaces should be more prominent, but I'd really like to avoid the idea of a "class", "table", etc. If an item has all the required properties, why shouldn't it be treated as that class? (If you disagree, you're not a Python programmer ;-) )

Peter writes:

sounds a lot like XML to me

comment

Aaron Sorkin Character Development 101

link comment

2007-01-25 21:03:40

Include one young, attractive, skinny, female secondary character with the appetite of a sumo wrestler in training and capitalise on the comedy of this in every scene they are in. Ensure plentiful supply of donuts, waffles and salad additives.

writes:

Have you got Studio 60?

Rachel writes:

that was me.

comment