Profile

Cover photo
Ian Hickson
Works at Google
Attended Bath University
1,200,207 views
AboutPostsPhotosYouTubeReviews

Stream

Ian Hickson

Free Pascal  - 
 
Sheesh, I really miss a looping construct where the condition is in the middle. Something equivalent to:

   repeat
      ...
      if (condition) then break;
      ...
   until false;

...but without the ugly "until false", and ideally with "continue" jumping to the block after the condition rather than back to the top.
1
Michael Schindler's profile photoIan Hickson's profile photoMario Ray Mahardhika's profile photo
10 comments
 
If the code duplication becomes a problem, I would replace part A with a procedure, possibly inlined. Sure, this is a fix and not the most elegant way, but for many practical problems it works good enough. I also assume, that a loop without continues and breaks is easier to optimize automatically for the compiler and easier to parallelize. On the other hand, you finally made me curious about this feature in Oberon.
Add a comment...

Ian Hickson

Shared publicly  - 
 
FYI, I updated Acid3 today to disable test 67, originally contributed by Sylvain Pasche, since it was testing attributes.removedNamedItemNS() which has since been removed from the DOM specification.

This change was requested by Ms2ger, who is affiliated with Mozilla.

People who are using archived versions of Acid3 can obtain an updated copy of the archive here: http://acid3.acidtests.org/acid3-2013-11-27.tar.gz
13
1
Paul Henning's profile photoMart Rootamm's profile photo
2 comments
 
To clarify a bit: I found out this April that the test worked in IE7 on early September 2011, but not soon after that.
Add a comment...

Ian Hickson

Shared publicly  - 
 
Discussions about DRM often land on the fundamental problem with DRM: that it doesn't work, or worse, that it is in fact mathematically impossible to make it work. The argument goes as follows:

1. The purpose of DRM is to prevent people from copying content while allowing people to view that content,

2. You can't hide something from someone while showing it to them,

3. And in any case widespread copyright violations (e.g. movies on file sharing sites) often come from sources that aren't encrypted in the first place, e.g. leaks from studios.

It turns out that this argument is fundamentally flawed. Usually the arguments from pro-DRM people are that #2 and #3 are false. But no, those are true. The problem is #1 is false.

The purpose of DRM is not to prevent copyright violations.

The purpose of DRM is to give content providers leverage against creators of playback devices.

Content providers have leverage against content distributors, because distributors can't legally distribute copyrighted content without the permission of the content's creators. But if that was the only leverage content producers had, what would happen is that users would obtain their content from those content distributors, and then use third-party content playback systems to read it, letting them do so in whatever manner they wanted.

Here are some examples:

A. Paramount make a movie. A DVD store buys the rights to distribute this movie from Paramount, and sells DVDs. You buy the DVD, and want to play it. Paramount want you to sit through some ads, so they tell the DVD store to put some ads on the DVD labeled as "unskippable".

Without DRM, you take the DVD and stick it into a DVD player that ignores "unskippable" labels, and jump straight to the movie.

With DRM, there is no licensed player that can do this, because to create the player you need to get permission from Paramount -- or rather, a licensing agent created and supported by content companies, DVD-CCA -- otherwise, you are violating some set of patents, anti-circumvention laws, or both.

B. Columbia make a movie. Netflix buys the rights to distribute this movie from Columbia, and sells access to the bits of the movie to users online. You get a Netflix subscription. Columbia want you to pay more if you want to watch it simultaneously on your TV and your phone, so they require that Netflix prevent you from doing this.

Now. You are watching the movie upstairs with your family, and you hear your cat meowing at the door downstairs.

Without DRM, you don't have to use Netflix's software, so maybe just pass the feed to some multiplexing software, which means that you can just pick up your phone, tell it to stream the same movie, continue watching it while you walk downstairs to open the door for the cat, come back upstairs, and turn your phone off, and nobody else has been inconvenienced and you haven't missed anything.

With DRM, you have to use Netflix's software, so you have to play by their rules. There is no licensed software that will let you multiplex the stream. You could watch it on your phone, but then your family misses out. They could keep watching, but then you miss out. Nobody is allowed to write software that does anything Columbia don't want you to do. Columbia want the option to charge you more when you go to let your cat in, even if they don't actually make it possible yet.

C. Fox make a movie. Apple buys the rights to sell it on iTunes. You buy it from iTunes. You want to watch it on your phone. Fox want you to buy the movie again if you use anything not made by Apple.

Without DRM, you just transfer it to your phone and watch it, since the player on any phone, whether made by Apple or anyone else, can read the video file.

With DRM, only Apple can provide a licensed player for the file. If you're using any phone other than an iPhone, you cannot watch it, because nobody else has been allowed to write software that decrypts the media files sold by Apple.

In all three cases, nobody has been stopped from violating a copyright. All three movies are probably available on file sharing sites. The only people who are stopped from doing anything are the player providers -- they are forced to provide a user experience that, rather than being optimised for the users, puts potential future revenues first (forcing people to play ads, keeping the door open to charging more for more features later, building artificial obsolescence into content so that if you change ecosystem, you have to purchase the content again).

Arguing that DRM doesn't work is, it turns out, missing the point. DRM is working really well in the video and book space. Sure, the DRM systems have all been broken, but that doesn't matter to the DRM proponents. Licensed DVD players still enforce the restrictions. Mass market providers can't create unlicensed DVD players, so they remain a black or gray market curiosity. DRM failed in the music space not because DRM is doomed, but because the content providers sold their digital content without DRM, and thus enabled all kinds of players they didn't expect (such as "MP3" players). Had CDs been encrypted, iPods would not have been able to read their content, because the content providers would have been able to use their DRM contracts as leverage to prevent it.

DRM's purpose is to give content providers control over software and hardware providers, and it is satisfying that purpose well.

As a corollary to this, look at the companies who are pushing for DRM. Of the ones who would have to implement the DRM, they are all companies over which the content providers already, without DRM, have leverage: the companies that both license content from the content providers and create software or hardware players. Because they license content, the content providers already have leverage against them: they can essentially require them to be pro-DRM if they want the content. The people against the DRM are the users, and the player creators who don't license content. In other words, the people over whom the content producers have no leverage. 
1063
613
Steve Faulkner's profile photoChristian Kaiser's profile photoErik Lentz's profile photoRoland Orre's profile photo
67 comments
 
What kind of world are you living in +Randall Arnold, in theory immaterial rights like patents (I refuse to use the weird collective term abbreviated  by IP...) would cover an implementation of a specific idea, but then came these abominations denoted "software patents" and "business model patents". Have you ever seen a software patent covering a specific method implemented in some particular language? No, it's pure monopolism on ideas!
Also when you study material patents you'll find that it's merely the idea behind a design which is patented. Then in English it's also a little confusing as "patents" can refer to "design patents" (bascially a specific pattern or shape) as well as the "idea patents" which most people associate with patents.

Ian Hickson

Shared publicly  - 
 
Heard about this on the Freakonomics podcast this week. If you have a decision you need to make, and you can't chose between two options, give this a try — it'll help you decide, and you contribute to science at the same time!
9
1
Fridrik Mar Jonsson's profile photo
 
I recommend going back to the early episodes -- it seems they're doing less of the more thorough pieces these days, but there's a lot of good stuff in there.

Ian Hickson

Shared publicly  - 
 
I recently wrote the following in an e-mail, but it seems suitable for a wider audience. tl;dr: I think it's more important for specs to be technically sound than it is to get consensus on them.

Consensus (also known as "design by committee") is a terrible way to design a language or platform. Committee design dilutes responsibility and blame (everyone just starts saying things like "yeah, I didn't like it, but we had to do that to get consensus") while letting everyone take credit for everything (since their ok is necessary to get consensus), which makes it an attractive proposition for people who want to further their careers without really doing any work. You also end up with people who arbitrarily disagree with things just so their voice is heard, you get political decisions ("I'll agree to your pet feature if you agree to mine"), you get specifications that feel like they've been written by fifteen people all with different styles, in short, you end up with a technology that doesn't know what it is and doesn't do anything well.

You get much better results by putting all the blame on one person, who then feels extremely motivated to not design something that sucks, while diluting the credit to all the people who are contributing solid technical information. This model pushes the people who don't want to do real work away, improves the quality of the final product, and provides an environment where if there are multiple completely divergent viewpoints, they can compete rather than being forced to ruin each other.

The other problem with "consensus" is the question of consensus among whom? In practice in specification working groups it ends up being consensus amongst those who bothered to show up, but this is almost always a non-representational group. For example, in some groups (e.g. W3C's WebApps group) implementors tend to be over-represented while authors and users are virtually absent. In others (e.g. IETF's hybi group) implementors of one conformance class (in this case servers) tend to completely outweigh implementors of another whose buy-in is actually more critical to the success of the technology (in this case browsers — WebSockets would have gone nowhere if none of the browsers implemented it, but would still have been a roaring success if only a fraction of server vendors cared to support it, since anyone can implement the server side). I've been in situations, e.g. the sXBL fiasco, where I've represented all the browser vendors in a group consisting of a dozen or more people, and if everyone agreed to something but me it was considered that we had consensus, even though in reality it meant none of the implementors were on board.

This is why "consensus" isn't a value I hold highly. Specs shouldn't be designed to consensus, they should be designed so that they end up solving real problems.

(Note that this does mean that there are certain stakeholders who need to be on board -- e.g. a majority of implementors for the key conformance class. So for example, for HTML, I need to make sure that whatever I spec is something that the bulk of implementors want to implement, otherwise it goes nowhere. But that's not consensus, it's just that "we won't implement that" is highly relevant technical feedback.)
60
30
Mark Warren's profile photoMax Kanat-Alexander's profile photoIan Hickson's profile photoShelley Powers's profile photo
31 comments
 
Several lead singers now; don't forget we now have several specs with several different editors. The lack of process is very intentional, so I'm glad it's recognisable.

Ian Hickson

Shared publicly  - 
 
The thing that's fascinating about the most recent Der Spiegel leaks about the NSA is that it makes a lot of the things that seemed unrealistic in spy TV shows and movies now seem positively mundane.

I never considered that if I bought a $2 USB cable online, I should expect the NSA to intercept the package and install a circuit board into the plug that turned the USB cable into a wifi device. Or that if I bought off-the-shelf Ethernet RJ45 plugs, they might be delivered after the NSA has installed MITM hardware in them. Or that the NSA might be illuminating my house with 1kW radar to power wireless microphones and keyboard loggers.
56
15
Rijk van Geijtenbeek's profile photoTshomarelo Matras's profile photo

Ian Hickson

Shared publicly  - 
 
Today we reached revision 8000 of the HTML standard. We started tracking revisions in March 2006, about two years after we started work on HTML in the WHATWG, which itself was about 6 months after we first started the work on updating HTML (when we first started, we called the work "XForms Basic", because we were trying to show that you could do much of what XForms did, by just extending plain old HTML — that work eventually made it into the forms section of the current HTML standard).

That's an average of three checkins a day, every day, for over seven years! That's what progress looks like. :-) Some checkins are trivial one-character typo fixes, some, like today's r8000, are big multi-thousand-line diffs (r8000 integrates the new <template> element into HTML, based on a proposal by Rafael (of Google) and Tony (of Microsoft), and implemented already in Chrome and Firefox).

As of right now my metrics tell me there's 1199 feedback e-mails remaining to process, and 156 bugs. So still lots of work to do.
69
11
Jim Cresswell's profile photoFred Gandt's profile photoJamie Hall's profile photoDonald Pipowitch's profile photo
6 comments
 
yeah! living standard is chaos theory in action :)

Ian Hickson

Shared publicly  - 
1

Ian Hickson

Shared publicly  - 
 
I don't understand what drives people to deny science, but it's killing the species.
23
14
emre tuncer's profile photoManuel Carrasco Molina's profile photoIan Hickson's profile photoOldřich Vetešník's profile photo
28 comments
 
I wish you continued.....

Ian Hickson

Shared publicly  - 
 
I have a bluetooth keyboard that's been bound to two separate computers, both in range. Normally, the keyboard is connected to one of these. Recently I did something (using just that keyboard) that made the keyboard instantly switch to being connected to the other computer. Any idea what keystroke that could possible have been? It was very confusing.
1
Emil A Eklund's profile photoIan Hickson's profile photoOjan Vafai's profile photoJeff Bailey's profile photo
13 comments
 
Oh, then it is probably some obscure keyboard combination. :(
People
Work
Occupation
HTML spec editor
Employment
  • Google
    Spec Weenie, 2005 - present
  • Opera Software
    QA & Standards, 2003 - 2005
  • Netscape
    Intern (QA & Standards), 2000 - 2001
Basic Information
Other names
Hixie, Hixie the Pixie
Story
Tagline
✔ Verified Geek and Cat Lover
Education
  • Bath University
    Physics, 1998 - 2001
Contact Information
Home
Email
The broccoli omelet tastes bland and watery. The home fries the same. The menu has items they don't sell. The juices are Tropicana bottles. On the plus side, the wait staff are very nice and friendly.
Public - in the last week
reviewed in the last week
Bland
Public - a month ago
reviewed a month ago
Food is flavourful and well presented, though the butter chicken is spicier than buttery. Service is friendly and accommodating, though easily confused.
Food: Very goodDecor: Very goodService: Good
Public - a year ago
reviewed a year ago
Public - 2 years ago
reviewed 2 years ago
24 reviews
Map
Map
Map
Bland and dry.
Public - 10 months ago
reviewed 10 months ago
Food: Very goodDecor: Very goodService: Good
Public - a year ago
reviewed a year ago