Put the knife down and take a green herb, dude. (c) Ruffin Bailey 2001-2021

I was listening to the Supertop Podcast today (you should too -- in the past, this show has had some great sponsors), and they were discussing Manton Reece's micro.blog Kickstarter, which added and met a stretch goal at $80k before it was all said and done.

I shelled out $10 to see the ebook, mostly because I'm intrigued, but not real sure what the project is about. On a past episode of Supertop, the guys mentioned that they weren't real sure what the project was precisely about themselves (EDIT: Turns out Daniel on Release Notes told Manton this same thing back on January 20th!).

Manton has discussed on his podcast, Core Intuition, several times about how much he's sweated the video for that Kickstarter (come to think of it, I don't think I ever watched!), but his real kicker (har har) is that he never actually precisely described what it was he's doing, so we're left to imagine micro.blog to be whatever we want it to be. It's a book about bringing back blogging, and it has a Twitter-like component. Not only that, it promises to "embrace... the open web". These are all laudable goals. Who wouldn't want to be on board?

But isn't that two services?

Interestingly, the stretch goal was...:

Stretch goal update: if we reach $80,000, I'll hire a community manager for Micro.blog to help build a safe community from the start. See this update on Kickstarter for details on the stretch goal and a new feature called Safe Replies.

A community manager? Wait, what? An open web service with a manager? How do you pull that off, exactly?

There are a number of obvious strategies. One is that the manager lords over a single server which is used to disseminate posts, and that your publishing process lets that server know as you're posting your content. Then others subscribe to that server in typical client-server fashion.

But that kills the open, doesn't it? Someone holds your access to your own subscriptions!

Maybe you could have a service that gives out guids for posts -- or even users -- that it doesn't feel a cultured schmoe would like to see, and your client uses those review services to pre-censor your open content. Nevertheless, management is much different than open.

I think a management/review service is a very different project from this one:

Do you remember how the web used to work? How the web was supposed to work?

In the earlier days of the web, we always published to our own web site. If you weren’t happy with your web host, or they went out of business, you could move your files and your domain name, and nothing would break.

Hopefully what this means is that we have two services. One is an open stack for publishing & consuming and the other is a review service that you can optionally use.

What is micro.blog?

Whether micro.blog is open or managed is precisely what I've wondered from the start. Manton's mentioned using (or replacing) Webmention, a w3c spec, a few times. That's an interesting move.

Webmention is sort of like an anonymously built webring -- remember those? When you'd slap a banner on your site so that anyone clicking could go to the "next, prev, or random" member of the same virtual community? Webrings built some of the first web-based, self-consciously social networks, versus, say, simply chatrooms and newsrooms based on topics, though I guess chatrooms and IRC were close.

Anyhow, webrings are sort of what Medium has effectively replaced. Now your blog has a social component [again]. Before, you had related conversations linked together. Now you link the conversations themselves. Webmention and Medium both accomplish this in one form or another.

What's necessary to have an open conversation?

But micro.blog is apparently more than that; it's also a Twitter replacement. And for that -- high intensity, short-form conversations broadcast publically -- you either have to subscribe to an RSS feed (or equiv) for someone's "micro blog posts" and then follow all reciprocally linked replies, or you'd have to have a centralized server which keeps track of unique names and collects and gives out all of the posts/information.

The first, a feed subscription, is a Webmention (or effectively a webring, though often even webrings had a server providing the "random" linking) like function. The second is a centralized client-server setup that's more susceptible to command and control. Even if there are, in theory, thousands of potential manager servers, it's still not really an open system.

And it's not really the openness that necessarily drives growth. I mean, there are already open Twitter alternatives. Building it doesn't mean that they'll come. There's a reason Twitter is still the 800 lbs gorilla.

Also remember that one of the giveaways for backing micro.blog was, "You can reserve your Micro.blog username even before the book is finished." Username? How is there a unique username on the open web without, say, an ICANN? Nonprofit or not, you're still centralized. Users won't own everything until you're using a mesh/p2p-ish network with the possibility of data collision -- and the algorithms to manage them. (Welcome to the world of public keys...)

In any event, I hope the book makes this stuff clear, and some folks bite on creating infrastructure. Even if Manton's holding the keys to "the" central server, it's an interesting experiment. How much can he offload hosting to keep costs down, but still provide reliable content? And how difficult would it be to make an Android client... ;^)

micro.blog is an interesting pie in the sky, but it's going to be a real pain to pull off and deliver on all the ambiguous promises it's perhaps unintentionally made. I wish him luck.

Labels: open, twitter, web 2.0 shiite

Finally started seriously scratching a new itch. I really disliked how difficult I'd found it to get a database engine working crossplatform for my C# "hobby" projects with MonoDevelop and, now, Xamarin Studio.

I'd considered using JSON or DataSet's WriteXML method to serialize data, but up until now, I'd been just writing stuff to text files to get hobby projects running more quickly. After using home-grown text file formats for years, though, it seemed dumb not to leverage SQL syntax. Yet every time I tried to find a good, crossplatform solution, I would waste hours not quite finding a great answer.

As I write in the new project's readme...

MVED# was written largely because of setup hurdles encountered attempting to deploy other obvious embedded database solutions for C# crossplatform. SQL Server Express is not crossplatform. SQLite must be installed on Windows and has a few nontrivial setup requirements on OS X, both of which create a clear barrier to entry out of proportion for applications with modest data serialization needs. C#-SQLite is an interesting alternative, but still had issues when I tried it out in May of 2012.

So back in February 24th of this year, I started hacking a database engine. And 121 commits to Bitbucket later, I finally have enough to put up on GitHub. (The GitHub/Bitbucket dynamic is also very interesting...) I can CREATE TABLE, INSERT, DELETE, SELECT, even INNER JOIN. I'm an UPDATE away from 80% of what I use "real" databases to accomplish. Well, if you ignore speed.

It's fun to look back over my commits, as always. There are almost zero commits in June and July, when work took a real turn for the busier. Seems like tons of late night commits. Also some interesting comments about where I was while I was coding...

Admittedly, there are tons of *cough* idiosyncratic behaviors in the engine, but much of this was an enjoyable alternative to the horribly defensive coding you have to do for customer-facing code. If I don't want to support ORs in WHERE clauses yet, well, I don't have to. If I want to support only INNER JOINs at first, that's my "right". Case sensitivity? Whitespace rules? All my decision. Bizarre! Want FLOATs to be stored as conventional DECIMALs for now? No problem (and more accurate too)! Unicode? Not yet! Why not? Because I chose [not] to! I'm drunk with power.

It was a heck of a lot of fun dealing with how to serialize each of the datatypes I'm supporting now. I did take a few old school-ish routes with storage while writing. Every column's length is absolutely fixed (VARCHARs really aren't VAR at all), largely to make the file's format really easy for users to eyeball, probably a leftover from having played around with 6507 assembler too much years ago. I even slap lines of 0x11s between columns to make it super-easy to view. Having easier-to-read files is probably not the best motivation for creating formats, but I'm happy with how it turned out.

Here's a crappy example of a raw "Moore's DataBase File (mdbf)" in the quick file viewer I wrote for the engine (click to see in any real detail).

Figuring out ways to serialize strings and decimal values was, honestly, fun. Doing this without much heavy "cheating" (more accurate would be "researching") was also a refreshing break from "serious" work, as this project is intended to be almost completely for [my] relaxation. Getting close to finished in about a tenth of the lines of C#-SQLite is, well, interesting. There's a lot that's not here. Parsing commands, even when you do get to choose what's syntactically legal, quickly gets, well, ugly. JOINs tend to bust what would otherwise be a pretty simple paradigm for parsing SELECTs -- heck, even SQLite currently doesn't support RIGHT OUTER JOIN. (Actually, reading that page, I feel a little of Hipp's pain (though let's make clear, since I'm talking about both in the same paragraph, that C#-SQLite is a port of SQLite by Noah Hart). GRANT and REVOKE don't mean so much when you're just hitting the file system, do they?)

Ultimately, writing MVED# reminded me a great deal of the shareware app I wrote years back. Eventually, even when you have nobody to answer to, code reaches the point where it's difficult to keep things idealistically organized. (Insert tangent about why it's so much more important to see a candidate's solution to a real-world problem than to simply interview, say, a new graduate about patterns when you're hiring.)

This project was also my first "real-world" use of the GNG Manfiesto. Even though MVED# could have easily gone under LGPL, I think there are going to be times where it's easier to use with the project's files compiled into a single app with new, closed files, so I opted for MPL 2.0 for now. Either way, it's open, demands changes by others to be shared, but allows others to use it as they'd like without compromising their own original, unrelated contributions, just as GNG demands.

Anyhow, to advert a little more plainly, the Minimally Viable Embeddable Datastore in C# (MVED#) or, as I called it as I developed it (since I wasn't worried a whit about performance), Moore's Database, can be found here:

https://github.com/ruffin--/mved/

It's not feature complete yet -- I'd like to sneak an UPDATE command handler in there before I do too much clean-up of existing code, which will be an easy refactor and then edit of the SELECT code -- but it's surprisingly close for what I think I'd like to use it for. A quick class for testing should follow UPDATE.

The code is hilariously simple. Optimizations are almost non-existent. Yet, at the same time, I think it's a horribly accessible codebase. We'll see. I'm going to use it. It works just as well on OS X as Windows, and that's a great start for my apps that need an embedded database solution. I can only assume Xamarin's going to make it pretty easy to use MVED# on Andriod and iOS too.

But okay, fine. I hear what you're thinking. If I have 121 commits and each one is, say, 30-45 minutes (let's go on the high side of that range and say 45 min, though admittedly I wonder how good of an estimate that is), that's 90 hours I didn't spend writing The Next Great Piece of Software with an existing engine. And it's not like I'm done yet. To me, that sort of cuts both ways. I'm surprised I'll be able to get a first functioning database engine in well less than three full-time weeks' of work, and I wonder if I'd waste that much time trying to get existing DBMSes working crossplatform. But then if I'd kept development to a primary platform and used the obvious DBMS engine for it, that's ~90 hours of work and months of free time I'd be ahead of where I am now to release an app for someone.

Regardless, it's been, and hopefully will continue to be, a fun project. Happy hacking.

Labels: coding, F/free, github, gng, mved, open, SqlDbSharp

title: Put the knife down and take a green herb, dude.	descrip: One feller's views on the state of everyday computer science & its application (and now, OTHER STUFF) who isn't rich enough to shell out for www.myfreakinfirst-andlast-name.com Using 89% of the same design the blog had in 2001.
FOR ENTERTAINMENT PURPOSES ONLY!!! Back-up your data and, when you bike, always wear white. As an Amazon Associate, I earn from qualifying purchases. Affiliate links in green.
x MarkUpDown is the best Markdown editor for professionals on Windows 10. It includes two-pane live preview, in-app uploads to imgur for image hosting, and MultiMarkdown table support. Features you won't find anywhere else include... MarkUpDown Multiline Table & Bootstrap Grid support. Beautiful Easy Actions that keep the Markdown flowing. HTML paste to paste HTML source into your documents. You've wasted more than $15 of your time looking for a great Markdown editor. Stop looking. MarkUpDown is the app you're looking for. Learn more or head over to the 'Store now!

Monday, January 10, 2022
Pot, kettle, Google on iMessage From The Verge: "Google says Apple ‘should not benefit from bullying’ created by iMessage lock-in." “iMessage should not benefit from bullying. Texting should bring us together, and the solution exists. Let’s fix this as one industry,” tweeted the official Android account. "Wow, that's rich." -Firefox Labels: apple, Google, open posted by ruffin at 1/10/2022 09:00:00 PM

Saturday, August 10, 2019
Apple Card locks away your financials Not being able to export your purchases is a fail from me, dawg. In a support document on how the Apple Card works, Apple says exporting data from Apple Card is not a feature offered at this time. From the document: "Exporting data from Apple Card to a financial app like Mint is not currently supported." [MacRumors] Seriously, I liked almost everything about Apple's "Everyperson Card" I'd heard until this. Your finances should not be locked in a walled digital garden. Labels: apple fail, credit, open posted by Jalindrine at 8/10/2019 01:17:00 PM

Friday, February 03, 2017
A [possible] critique of micro.blog I was listening to the Supertop Podcast today (you should too -- in the past, this show has had some great sponsors), and they were discussing Manton Reece's micro.blog Kickstarter, which added and met a stretch goal at $80k before it was all said and done. I shelled out $10 to see the ebook, mostly because I'm intrigued, but not real sure what the project is about. On a past episode of Supertop, the guys mentioned that they weren't real sure what the project was precisely about themselves (EDIT: Turns out Daniel on Release Notes told Manton this same thing back on January 20th!). Manton has discussed on his podcast, Core Intuition, several times about how much he's sweated the video for that Kickstarter (come to think of it, I don't think I ever watched!), but his real kicker (har har) is that he never actually precisely described what it was he's doing, so we're left to imagine micro.blog to be whatever we want it to be. It's a book about bringing back blogging, and it has a Twitter-like component. Not only that, it promises to "embrace... the open web". These are all laudable goals. Who wouldn't want to be on board? But isn't that two services? Interestingly, the stretch goal was...: Stretch goal update: if we reach $80,000, I'll hire a community manager for Micro.blog to help build a safe community from the start. See this update on Kickstarter for details on the stretch goal and a new feature called Safe Replies. A community manager? Wait, what? An open web service with a manager? How do you pull that off, exactly? There are a number of obvious strategies. One is that the manager lords over a single server which is used to disseminate posts, and that your publishing process lets that server know as you're posting your content. Then others subscribe to that server in typical client-server fashion. But that kills the open, doesn't it? Someone holds your access to your own subscriptions! Maybe you could have a service that gives out guids for posts -- or even users -- that it doesn't feel a cultured schmoe would like to see, and your client uses those review services to pre-censor your open content. Nevertheless, management is much different than open. I think a management/review service is a very different project from this one: Do you remember how the web used to work? How the web was supposed to work? In the earlier days of the web, we always published to our own web site. If you weren’t happy with your web host, or they went out of business, you could move your files and your domain name, and nothing would break. Hopefully what this means is that we have two services. One is an open stack for publishing & consuming *and the other* is a review service that you can optionally use. What is micro.blog? Whether micro.blog is open or managed is precisely what I've wondered from the start. Manton's mentioned using (or replacing) Webmention, a w3c spec, a few times. That's an interesting move. Webmention is sort of like an anonymously built webring -- remember those? When you'd slap a banner on your site so that anyone clicking could go to the "next, prev, or random" member of the same virtual community? Webrings built some of the first web-based, self-consciously social networks, versus, say, simply chatrooms and newsrooms based on topics, though I guess chatrooms and IRC were close. Anyhow, webrings are sort of what Medium has effectively replaced. Now your blog has a social component [again]. Before, you had related conversations linked together. Now you link the conversations themselves. Webmention and Medium both accomplish this in one form or another. What's necessary to have an open conversation? But micro.blog is apparently more than that; it's also a Twitter replacement. And for that -- high intensity, short-form conversations broadcast publically -- you either have to subscribe to an RSS feed (or equiv) for someone's "micro blog posts" and then follow all reciprocally linked replies, or you'd have to have a centralized server which keeps track of unique names and collects and gives out all of the posts/information. The first, a feed subscription, is a Webmention (or effectively a webring, though often even webrings had a server providing the "random" linking) like function. The second is a centralized client-server setup that's more susceptible to command and control. Even if there are, in theory, thousands of potential manager servers, it's still not really an open system. And it's not really the openness that necessarily drives growth. I mean, there are already open Twitter alternatives. Building it doesn't mean that they'll come. There's a reason Twitter is still the 800 lbs gorilla. Also remember that one of the giveaways for backing micro.blog was, "You can reserve your Micro.blog username even before the book is finished." Username? How is there a unique username on the open web without, say, an ICANN? Nonprofit or not, you're still centralized. Users won't own everything until you're using a mesh/p2p-ish network with the possibility of data collision -- and the algorithms to manage them. (Welcome to the world of public keys...) In any event, I hope the book makes this stuff clear, and some folks bite on creating infrastructure. Even if Manton's holding the keys to "the" central server, it's an interesting experiment. How much can he offload hosting to keep costs down, but still provide reliable content? And how difficult would it be to make an Android client... ;^) micro.blog is an interesting pie in the sky, but it's going to be a real pain to pull off and deliver on all the ambiguous promises it's perhaps unintentionally made. I wish him luck. Labels: open, twitter, web 2.0 shiite posted by ruffin at 2/03/2017 01:57:00 PM

Thursday, November 14, 2013
"Microsoft’s OpenXML SDK is [like]... Assembly language" Making OpenXML Easy with ClosedXML: Microsoft’s OpenXML SDK is to OpenXML documents like the Assembly language is to processors. You can use it to get your work done but it takes a tremendous amount of effort to do anything. Exceptionally well put. It's open qua all in XML, but only in the manner that Microsoft Word is open because I can see its bytecodes. Labels: hats of money, microsoft, ooxml, open posted by ruffin at 11/14/2013 02:20:00 PM

Saturday, November 02, 2013
MVED# (Minimally Viable Embeddable Database in C#) on GitHub. Finally started seriously scratching a new itch. I really disliked how difficult I'd found it to get a database engine working crossplatform for my C# "hobby" projects with MonoDevelop and, now, Xamarin Studio. I'd considered using JSON or DataSet's WriteXML method to serialize data, but up until now, I'd been just writing stuff to text files to get hobby projects running more quickly. After using home-grown text file formats for years, though, it seemed dumb not to leverage SQL syntax. Yet every time I tried to find a good, crossplatform solution, I would waste hours not quite finding a great answer. As I write in the new project's readme... MVED# was written largely because of setup hurdles encountered attempting to deploy other obvious embedded database solutions for C# crossplatform. SQL Server Express is not crossplatform. SQLite must be installed on Windows and has a few nontrivial setup requirements on OS X, both of which create a clear barrier to entry out of proportion for applications with modest data serialization needs. C#-SQLite is an interesting alternative, but still had issues when I tried it out in May of 2012. So back in February 24th of this year, I started hacking a database engine. And 121 commits to Bitbucket later, I finally have enough to put up on GitHub. (The GitHub/Bitbucket dynamic is also very interesting...) I can CREATE TABLE, INSERT, DELETE, SELECT, even INNER JOIN. I'm an UPDATE away from 80% of what I use "real" databases to accomplish. Well, if you ignore speed. It's fun to look back over my commits, as always. There are almost zero commits in June and July, when work took a real turn for the busier. Seems like tons of late night commits. Also some interesting comments about where I was while I was coding... Admittedly, there are tons of *cough* idiosyncratic behaviors in the engine, but much of this was an enjoyable alternative to the horribly defensive coding you have to do for customer-facing code. If I don't want to support ORs in WHERE clauses yet, well, I don't have to. If I want to support only INNER JOINs at first, that's my "right". Case sensitivity? Whitespace rules? All my decision. Bizarre! Want FLOATs to be stored as conventional DECIMALs for now? No problem (and more accurate too)! Unicode? Not yet! Why not? Because I chose [not] to! I'm drunk with power. It was a heck of a lot of fun dealing with how to serialize each of the datatypes I'm supporting now. I did take a few old school-ish routes with storage while writing. Every column's length is absolutely fixed (VARCHARs really aren't VAR at all), largely to make the file's format really easy for users to eyeball, probably a leftover from having played around with 6507 assembler too much years ago. I even slap lines of 0x11s between columns to make it super-easy to view. Having easier-to-read files is probably not the best motivation for creating formats, but I'm happy with how it turned out. Here's a crappy example of a raw "Moore's DataBase File (mdbf)" in the quick file viewer I wrote for the engine (click to see in any real detail). Figuring out ways to serialize strings and decimal values was, honestly, fun. Doing this without much heavy "cheating" (more accurate would be "researching") was also a refreshing break from "serious" work, as this project is intended to be almost completely for [my] relaxation. Getting close to finished in about a tenth of the lines of C#-SQLite is, well, interesting. There's a lot that's not here. Parsing commands, even when you do get to choose what's syntactically legal, quickly gets, well, ugly. JOINs tend to bust what would otherwise be a pretty simple paradigm for parsing SELECTs -- heck, even SQLite currently doesn't support RIGHT OUTER JOIN. (Actually, reading that page, I feel a little of Hipp's pain (though let's make clear, since I'm talking about both in the same paragraph, that C#-SQLite is a port of SQLite by Noah Hart). GRANT and REVOKE don't mean so much when you're just hitting the file system, do they?) Ultimately, writing MVED# reminded me a great deal of the shareware app I wrote years back. Eventually, even when you have nobody to answer to, code reaches the point where it's difficult to keep things idealistically organized. (Insert tangent about why it's so much more important to see a candidate's solution to a real-world problem than to simply interview, say, a new graduate about patterns when you're hiring.) This project was also my first "real-world" use of the GNG Manfiesto. Even though MVED# could have easily gone under LGPL, I think there are going to be times where it's easier to use with the project's files compiled into a single app with new, closed files, so I opted for MPL 2.0 for now. Either way, it's open, demands changes by others to be shared, but allows others to use it as they'd like without compromising their own original, unrelated contributions, just as GNG demands. Anyhow, to advert a little more plainly, the Minimally Viable Embeddable Datastore in C# (MVED#) or, as I called it as I developed it (since I wasn't worried a whit about performance), Moore's Database, can be found here: https://github.com/ruffin--/mved/ It's not feature complete yet -- I'd like to sneak an UPDATE command handler in there before I do too much clean-up of existing code, which will be an easy refactor and then edit of the SELECT code -- but it's surprisingly close for what I think I'd like to use it for. A quick class for testing should follow UPDATE. The code is hilariously simple. Optimizations are almost non-existent. Yet, at the same time, I think it's a horribly accessible codebase. We'll see. I'm going to use it. It works just as well on OS X as Windows, and that's a great start for my apps that need an embedded database solution. I can only assume Xamarin's going to make it pretty easy to use MVED# on Andriod and iOS too. But okay, fine. I hear what you're thinking. If I have 121 commits and each one is, say, 30-45 minutes (let's go on the high side of that range and say 45 min, though admittedly I wonder how good of an estimate that is), that's 90 hours I didn't spend writing The Next Great Piece of Software with an existing engine. And it's not like I'm done yet. To me, that sort of cuts both ways. I'm surprised I'll be able to get a first functioning database engine in well less than three full-time weeks' of work, and I wonder if I'd waste that much time trying to get existing DBMSes working crossplatform. But then if I'd kept development to a primary platform and used the obvious DBMS engine for it, that's ~90 hours of work and months of free time I'd be ahead of where I am now to release an app for someone. Regardless, it's been, and hopefully will continue to be, a fun project. Happy hacking. Labels: coding, F/free, github, gng, mved, open, SqlDbSharp posted by ruffin at 11/02/2013 10:56:00 PM

Saturday, October 05, 2013
Arguing that minimized JavaScript is in "Executable form" MPL 2.0 FAQ: Q16: Is "minified" JavaScript Source Code? No. Minified JavaScript, while not an "executable" in the software engineering sense of the word, is difficult for humans to read, edit, and modify. As such, it is not "the preferred form for modification" and so it is not Source Code as defined by the license. Therefore, minified JavaScript is the Executable form, and the responsibilities set out in the license for distribution of the Executable form should be met when you distribute minified MPL-licensed JavaScript. Compare to OOXML. Like interpreted code, you could (and, I believe) should argue that purposely obfuscated human-readable code and standards are operating as executable/proprietary code. Labels: javascript, licensing, mozilla, ooxml, open posted by ruffin at 10/05/2013 06:05:00 PM

Wednesday, September 18, 2013
Why use mashed proprietary when you can obfuscate? Get Kingsoft Office Professional 2013 (Win) free \| The Cheapskate - CNET News: al_chirico @Cool_Daddy For me, I like being able to actually read the data file. The xxxX formated files are XML files. So, If you know XML or HTML, you can just search the file for something you're looking for. This is especially helpful if you're passing a xxxX file to another program. You can just deconstruct the file as input data. Try doing that with an earlier xxx file. Just my 2 cents. I read through this comment that's essentially in favor of the use of Microsoft's "Office Open XML" file formats and came away with an unexpected take-home. First, why should we care how hard it is to open a .doc file in a text editor at this point? We have plenty of excellent, freeware applications that can do that job for us (AbiWord, though seemingly dead, is still one of my favorites). There's no real practical advantage for having a .doc file in a human readable file format now, is there, minus outliers like, "I just installed my OS and have no internet access and MUST edit the contents of my file in the 'pack-in' text editor!" But then I shift from the consumer's pov to Microsoft's. If the long game says that proprietary file formats will be broken and provide no (again, long-term) advantage, why bother with them at all? Why not just use XML for your file format? The format's so complex at this point, the degree of obfuscation in XML versions of the files is still tremendous. You're past the point of something simply reproduced -- heck, even MS's Mac Business Unit had a heck of a time pulling it off, and that was an inside job! It's the difference between html made by Seamonkey Composer and html made by Word's "Save As HTML". HTML is supposed to be a nice, human-editable format. Yet one product is pretty easy to edit by hand, and the other nearly impossible. (See also AbiWord's Save As HTML for docs; beautiful stuff.) So why move from bytecode to XML if you're Microsoft? XML might be a better tool for serializing docs, and puts contracts with governments that demand "free and open" (and therefore, ostensibly, forward compatible and archival) formats back on the table and kill the "open" movement flat. And there's really no difference to the end user now either, minus those guys who post to CNET and claim to be opening/editing their docs in Notepad. ;^) Microsoft moving to XML seems better, but, in the end, holds the status quo. (C#'s release as an open standard, however, had much different, more beneficial results. Wonder if that was expected?) Labels: microsoft, ooxml, open, xml posted by ruffin at 9/18/2013 01:03:00 PM

Tuesday, October 16, 2012
Open source software reducing piracy? This is a relatively interesting take -- if offices need specific pieces of office software, there's no free alternative, and you don't have the budget for Microsoft, what do you do? ProjectLibre: October 2012 Project of the Month \| SourceForge Community Blog: Rich: So far as the third world goes, there’s an enormous amount of illegal software use. Your project and ones like it also fill a role there. Can you talk a bit about that? Marc [ProjectLibre lead, I think]: I really feel passionately about this because it is a moral dilemma, around the world, whether you manage your project on a spreadsheet or whether you pay $1000 a copy for Microsoft Project or other proprietary vendors. Guess that makes sense. Labels: open, piracy posted by ruffin at 10/16/2012 01:47:00 PM

Sunday, September 16, 2012
How Free software isn't enough to guarantee f/Freedom FOSS Patents: If Google can cancel Acer's license, why should Apple have to grant one to Google?: Acer is a member of the Google-dominated "Open Handset Alliance" and was about to release a smartphone running an Android fork named Aliyun, which was created by Alibaba, a Chinese Google competitor, but Google essentially says: "you're with us or you're against us". You can be a member of the OHA and an official licensee of Android, or you want to distribute forks (derivative programs), in which case we'll throw you out of the OHA and cancel your official Android license. Google got its way. Android's non-openness is old news, and nothing I could say would counterbalance the deafening silence and open double standards of various "free software" and "open source" luminaries and entities. It's strange, but endlessly fascinating, how corporations configure themselves around Free and open source licensing. Some places use GPL'd software on their server, but argue that's not distribution, so they're not under any obligation to release the source (I've forgotten how the argument goes, but I've worked for people who claim it). Others, like that bizzarre kickup around MySQL, have strange forks of code into Free and non-Free codebases. Did MySQL really never incorporate anything submitted by the community? Or there's the dual licensed stuff, which really isn't a huge deal unless you're doing it retroactively, like Mozilla, where, iirc, some stuff had to be rewritten before the new licensing was done. And here, it's not the code so much as the access to the coders. Support is worth as much as the code in some cases, especially when the code is especially complex, like I'm assuming Android is. Probably more important here is early access to Google's R&D, which Acer stands to lose if its most favored nation status is revoked. It's hard not to exploit Free software. Apple didn't always play nice with WebKit and Darwin (and still doesn't give back everything, I'm sure), and, in Darwin's case, wasn't under any compulsion to do so. With webkit, we're lucky to have an Apple that follows the LGPL as closely as they do, I'm afraid. Android, in my opinion, pretty obviously stole some of Java. GPL'd software has been discovered in a number of closed source products. Google's maneuvering of cultural affiliation, loosely de/coupled with and from open source software, is the obvious move. I wonder if RMS would (or, perhaps better asked, should) even be against what Google is doing. Should you get to see Free software as it's being developed, before it's released? Is Android the perfect example of how open source can power commerce? Labels: android, apple, free, Google, gpl, lgpl, licensing, linux, open posted by ruffin at 9/16/2012 02:11:00 PM

Monday, July 23, 2012
Why BSD is evil in nine words or less. Recently, there was an OSNews article called "Sparrow's acquisition highlights the dangers of closed source". I think there are issues enough with the logic in that statement alone, so I got baited into reading. Sparrow, I guess I should add, is a pretty neat (though low featured, afaict) stand-alone email application for OS X. People like it. Google bought it. Now there will be no new Sparrows and, more importantly, no Sparrow for iPad, which they'd been working on recently. Buying Sparrow was very likely, I believe, a talent acquisition move for Google. They're buying the programmers as much or more than the code. Regardless, apparently the OSNews author believes that if Sparrow had been open source, it'd be reasonable to expect the next version of Sparrow to come out on time and under budget in spite of the developers leaving. And I guess the implication is that Sparrow would have grown just as quickly and been just as personally lucrative for the developers if it were an open source project as it did as a closed source one (wait... what?). Such an argument is pretty sad. Open Source only protects you from your favorite app's going kaput if you have programmers ready to contribute, and usually to contribute for free. I've posted a couple of times that I'm reading Dreaming in Code, the book about the Chandler Project. Some folks seem to enjoy the app. It's open source. Chandler's also essentially dead. Thunderbird is open source. It's in stasis mode too. Open source does not protect you from a project's death. It does allow a group of programmers to pick up where the original team stopped. And if you've ever inherited code, you know what a bear coming to a brand new codebase can be. Let's just say it's often a theoretical possibility, but practical nightmare. Every program is a cyborg. Completely remove the original human element -- the original developers -- and the cyborg likely dies. Google's hiring Open-Sparrow's developers kills Open-Sparrow just as surely as this kills Closed-Sparrow. The difference? At least Closed-Sparrow's programmers made enough cash to keep them interested to this point in the game. Show me a project that went -- entirely unfunded -- from commercial to successful open source project. Closed source protects small programming shops. There's no way around it. There are a few exceptions that prove the rule where donations fund projects, but I don't know that any were initially closed-source commercial projects. More importantly, it's hard to sell software as a business model using free software. Services, fine, you can sell yourself as someone who provides services for OSS, but there's not a huge market for email-app-related services. Not many calls from people waiting to spend $120/hour for you to configure Sparrow. Lots more willing to pay for the app or to click your, in my case at least, surprisingly well-targeted ads. Regardless, replying to a comment to the OSNews post, I believe I convinced myself of why BSD is evil in nine words or less. OSNews > Thread > "RE: Whining because they are Apple fanboys?" by Macrat: RE: Whining because they are Apple fanboys? by Macrat on Sun 22nd Jul 2012 02:33 UTC in reply to "Whining because they are Apple fanboys?" Member since: 2006-03-27 Your suggestion - that Apple users consider open source - is like asking a group of religious fanatics to convert to atheism. All Mac users are using open source as open source apps come with OS X. http://www.apple.com/opensource/ Reply Parent Score: 3 RE[2]: Whining because they are Apple fanboys? by rufwork on Mon 23rd Jul 2012 13:52 in reply to "RE: Whining because they are Apple fanboys?" Member since: 2012-07-23 The important thing to remember is that the OS is using BSD-licensed stuff under the hood. That means it was open source, but isn't any more. The BSD is far too permissive, and doesn't protect software. I'm surprised it's considered an Open-as-in-Free license at all sometimes. "Please plagiarize my code and call it your own! I'm begging you!" Reply Parent Score: 1 And that's really the rub for me. BSD allows a situation where *it was* open source, but it isn't any more.** Thank you, me, for putting that succinctly. Based on the length of your typical post, including the preamble to this one, I'm surprised you were able to come through like that for us. Labels: apple, bsd, copyright, gng, licensing, open, os x, OSS posted by ruffin at 7/23/2012 10:38:00 AM

Friday, July 06, 2012
Missing MySQL's move to Oracle -- Copyleft and Hats of Money Recently, Real Software posted a blog post that said that Real Basic works with MySQL, but that you'd have to open source any Real Basic app that used it. Real Studio is able to connect to the Community (free) edition of MySQL, but this edition usually requires you to open source software that connects to it (due to its GPL license). I didn't think that was right. Obviously, you can use MySQL without open sourcing code the same way you can write an app with GNU/Linux and release it closed source. If MySQL was that "viral", almost every two bit app on some cheap php hosting environment is now GPL'd. Turns out it's more complicated, apparently. It might be that the Real Software plugin that talks to MySQL is GPL'd. I don't know how that'd happen. Can't Real just get a MySQL commercial license and start coding? Regardless, the post got me thinking about MySQL licensing. And that, though I'm over two years late to the party, seems to be a lot of fun. Groklaw - Monty Program AB's Suggestion to EU Commission to Get Rid of the GPL on MySQL - Updated: So that is why they care. They have big plans for a business around MySQL, and they want to make some money from it. MariaDB is their fork of MySQL. Of course, there's nothing wrong with making money. Notice the role of the Open Database Alliance in all this, in case anyone tells you there is no connection. There is. I'm not sure I understand how the sort of dual-licensing many open source but commercially funded apps work. There's no way that MySQL-Cash isn't somehow benefitting from impressive changes and fixes to MySQL-Altruism. (My guess is that they pretend to have a "clean room", have someone walk in, view the OSS MySQL code, then walk out, across the hall, and do the same thing from memory to the closed version.) But companies do this, pretending that the open source version is completely and irrevocably downstream of the closed source version, and one of the MySQL co-founders apparently wanted to have his cake and eat it twice. He wanted to relicense MySQL under the Apache license so, essentially, he could do whatever the heck he wanted to do with the closed MySQL codebase at his new company without releasing that code rather than have to open source his fork of MySQL. That is, unless he bought a license to develop MySQL from the closed source, his only avenue to fork was to fork the GPL version. Oh noes! Which, of course, suggests that there's a fair bit of code in MySQL-Cash that we're not seeing in MySQL-Altruism. Apparently that threw the world on its ear. IBM said that Oracle could buy Sun (and, with it, MySQL), but some little schmoe (above) disagreed. The sale was held up, and millions of bucks allegedly lost during the deliberation. Fine. The worst part? Some wicked pixelers started saying stuff like this: And in the ultimate irony, Richard Stallman himself joined the fray against... Richard Stallman? /sigh No, no he didn't. But that didn't stop the world from deciding that the GPL prevented you from forking code. WTF? RLY? Come on. Get a new job writing about whatever it is that you're really interested in, because it sure ain't the GPL. Here's a quote from a horribly written piece on CNet called "Stallman: GPL doesn't guarantee software freedom". Even Richard Stallman, co-author of the GPL and founder of the free-software movement, and not someone that spends much time worrying about monetization of open-source software, gets this. As noted in a letter co-drafted with Open Rights Group and Knowledge Ecology International, Stallman notes that Oracle's proposed acquisition of MySQL could hurt its development because the GPL reduces incentives to commercialize the code. Come on, that wasn't enough for you to wonder what was going on? You really thought RMS was arguing for Apache over GPL? To what ends? (Sorry -- I don't usually bash like this, but the FUD here is insane, and so easily seen through.) A commenter on this story has a much better answer/handle on this situation. It's so good, I'm posting it all, in case the story disappears. "mbenedict" is the author. There are many issues here getting mixed up. First, in fairness to Stallman, when he talks about a "lack of a more flexible license" for MySQL he's really talking about GPL v3 -- or more specifically mixing v2 and v3 code together in a possible future fork. Matt's selective quoting above seem to misrepresent Stallman's position by removing its context. Second, even under GPL v2, there is nothing preventing a "MySQL 2" to "arise, take the code, hire all of the developers, and development of the open-source database would not miss a beat." A new entity under GPL can fork MySQL code and do all that. What the new entity cannot do is re-license the forked code under a different license -- including GPL v3, or a separate Commercial License under a dual-licensing scheme. So we finally get into the crux of the issue which Matt curiously omits: dual-licensing of GPL v2 code. We all knew it was "evil". Now we're all acting surprised that it could be "evil". Dual-licensing allows companies to give out crack to babies, and then charge them $$$ once they're hooked... completely against the spirit of GPL. Now, I'm not a fan of GPL. I've been a long proponent for BSD-style licenses (which Apache derives from). Lots of companies "talk" about relicensing from GPL to Apache... but actions speak louder than words. Okay, okay, okay. Let's stop mbenedict at one spot -- BSD? Insane. "Please steal my code! Make hats of cash! Give me nothing! Just know that you can't sue me." Or, as I've said before, those licenses "essentially enable legalized plagiarism". That's crazy. Well meaning, perhaps (more likely too business oriented and not written by a guy who actually contributes to open source code), but crazy. There's a perfect license for releasing code into the world for commercial companies to use: The LGPL. It's fair. It encourages passive collaboration (OSS' biggest boon) from commercial enterprises (a rare but powerful thing). And, get this, it fairly requires that if they improve the functions you gave them, they must give back to you those -- and only those -- improvements. Brilliant! That's what The GNG Manifesto is all about. I think you get the point. RMS is anti-GPLv2 insofar as it's not the GPLv3. He likes GPLv3, but thinks it should have more flexibility for users to change their project's license as changes to the GPL are made. He does not like Apache licenses more than GNU licenses. MySQL should, for RMS, be licensed under GPLv3, though v2 and v3 allow you to fork. What a media fail. Labels: gpl, hats of money, licensing, mysql, open, OSS posted by ruffin at 7/06/2012 09:20:00 AM

Friday, November 25, 2011
How to add a footnote in Microsoft Word Starter I've been using Word Starter a lot recently. For some reason, it's all I've got at work, and it's also on the new HP subcompact (d1m) I finally received last week. It's not bad, and it even is nice enough to support the menu-based keyboard shortcuts I'm used to using. But when I tried to add a footnote -- I think that's Alt-I-N -- nothing happened. It sat around waiting for me to hit something after I. Perhaps I'm using Word 2000 shortcuts, or perhaps I just didn't remember correctly. But perhaps I can't add a footnote? If you check the help to see how to add a footnote, Word Starter'll tell you that, sure enough, you can't add a footnote to a document. Microsoft Word Starter 2010 is a simplified version of Word that comes pre-loaded on your computer. Word Starter includes features that are basic to creating and working with documents, but it does not include the rich set of features found in the full version of Word. This article lists the differences in features between Word Starter and the full version of Word. If you find that you need a richer set of features than what Word Starter provides, you can easily upgrade from Word Starter to Word. On the Home tab, click Purchase to visit an online retailer, where you can purchase and download Office right away. That's cute. Here's the footnote specific jive: Footnotes and endnotes Not available to create If you open a document that contains footnotes or endnotes, you can click the footnote or endnote link to jump to the footnote or endnote. You can also cut, copy, or paste the footnote or endnote, and you can format the text. Hrm. That seems weird. What if I want to move text that has a footnote by cutting and pasting? What if I want to duplicate text by copy and pasting? Does the footnote go away? No, and that's how you add 'em. Highlight the footnote, copy, and paste in somewhere else. Now edit from the old footnote text to the new. Of course, this requires that you have a doc to cut and paste from that already has a "donor" footnote. Hey, look! Here's one now! (Though always be wary of taking Word docs from strangers.) It's an interesting move by Microsoft -- you're essentially giving Word away for free, except for those who don't like feeling constricted when they edit, in spite of the fact that pretty much everything is still there. Wonder how much we can thank OpenOffice for this? Labels: open, Word posted by ruffin at 11/25/2011 04:29:00 PM

Wednesday, September 07, 2011
Google - open without being open? Open after the fact The presentation slide is titled, "If we gave it away, how can we ensure we get to benefit from it?" and recommends a set of policies that include "Do not develop in the open. Instead, make source code available after innovation is complete." Not that Apple doesn't do the same thing... Still, it's important to understand that open doesn't necessarily mean OPEN. Labels: Google, open posted by ruffin at 9/07/2011 06:58:00 PM

Wednesday, May 11, 2011
Google's Animated Doodle: Technology Overkill? Dynamic Google doodle draws dancers, complaints \| Deep Tech - CNET News: Today's Google doodle honors choreographer Martha Graham's birthday--and with animated dancers revealing it, the doodle also showcases the company's push to build a more dynamic Web. The only problem: some people find it's slowing their machines. That's hardly the outcome that Google--obsessed over every millisecond of delay in delivering search results--could have wanted. The interesting thing here is that the animation is apparently all done with dhtml instead of, say, an animated gif, which would have done just as well. The code is a mess. And using the javascript engine to power your animation as well as your keystroke sensing is a little cannibalistic. It's like ethanol -- there's no inherent reason that corn prices should be directly and immediately influenced by gasoline price until we started feeding our mouths and tanks with the same stuff. It's a ill-fated confluence of convenience. Google's "everything's a nail" attitude also reminds me of what the Free Software Foundation is trying to call "The Javascript Trap. Because Gmail's interface online is full of proprietary code, the FSF has decided they'd like to tell their mail list subscribers to stop using that fully-featured web app. You may not be aware of the dangers of JavaScript -- a problem we've deemed The JavaScript Trap -- proprietary software running on your computer, inside your web browser. ... When you visit a website such as Gmail, your browser will download and run several thousand lines of JavaScript code. This JavaScript code is no different to other programming languages -- applications written in those languages running on our computers should be free software, so we can run, modify and share them if we wish. It's an interesting line, but a flawed one (my first reaction was a solid "Oh noes!"), I think. The Javascript is still out there for you to review and edit. It's heavily obfuscated, even moreso than decompiling many Java or .NET apps, I'd argue, but it's still out there. The FSF should be more worried about the proprietary software on the Gmail servers. They suggest IMAP and Thunderbird is the way to go, which is nice, but they obviously haven't used Thunderbird recently. (I kidded hyperbolically) I wonder if Javascript on your browser isn't in some sense a use of a little-"o" open source medium that is more in tune with FSF than, say, Outlook. Sure you've still got the assembler/machine code of Outlook -- any app is just a bunch of zeroes and ones -- so you could argue it's open too, but Gmail is several steps closer. I did email Mr. Lee, who sent out an email to me (and everyone else) saying that I should stop using Gmail's online interface. Here's a bit of my replies. Though I expect Google's Javascript is copyrighted, it would seem that studying the Javascript is still possible, isn't it? I'll admit I haven't checked the code, but each include file, etc, is downloaded to your browser, so we're a few cURLs away from the source, aren't we? What's different here? ... [he's nice enough to reply, and I send another]... There's nothing illegal about having your browser interpret Javascript differently, is there? We can turn off window.open, eg, having our browsers censor or rewrite code. There's an implicit openness to and ability to modify the interpretation of [little "o"] open Javascript already. Extend Tor and interpret away, (c) or no. Like Java, the code's all there by virtue of the system, you know? Your Gmail protest is really arguing that Free also implies "written for humans", which is a point I really appreciate. It'd be great to see that slant foregrounded more in FSF posts and projects. Open source is, ultimately, all about the human readability, isn't it? The "Javascript trap" really means that you can't stop at open. If I obfuscate my Java as part of the compilation process and release the obfuscated code, it's not really Open is it? Still, Google's mastery and overuse of Javascript is an excellent point. What are they doing with our browsers? Why are they willing to compromised their own functionality to recreate the animated gif or SVG? And even though their interface seems very simplistic to the point of minimalism, which platforms are part of the Google web and which aren't? Labels: F/free, FSF, gmail, Google, javascript, online distribution, open posted by ruffin at 5/11/2011 11:02:00 AM

Thursday, March 31, 2011
Open source as an opening strategy From AppleInsider \| Google clamps down on handset makers to stem Android fragmentation: Though it has long heralded Android as 'open,' Google has recently taken other steps to gain control of its mobile platform. Just last week, it was revealed that the company had closed availability of the source code of Android 3.0 Honeycomb, a tablet-specific version of its platform. There's a new-ish mode of engagement with open source that's open source once we're done with it. This allows people thinking about adopting the packages to vet everything fairly well and to mitigate the dangers of being unsupported in the future if, here, Google's support for Android died. But what it allows the provider to do is to retain rights to every bit of code, and fork into a proprietary branch their future development. That is to say, if you release a package you've written completely by yourself under the GPL and never accepted patches, you could then release version 2 based on the same code as a copyrighted, proprietary, closed source piece of software. That's what Google's doing with Android. You initially get more adoption than a closed platform because the source is out there for anyone to maintain if they need to so that they can keep selling hardware, but once enough folk use it (initially for that but later for other reasons, like broad adoption), BAM, close up shop. You've gotten the adoption benefits of open source with the later benefits of proprietary lock-in thanks to planned obsolescence driven by consumer capitalism. It's sort of the issue with BSD for me. BSD really isn't Free Software, precisely because it's too freely (little "f") exploited. OS X is here thanks to FreeBSD's overly unrestrictive license. We'll never see tons of the changes Apple made to the codebase, and are lucky to have gotten anything from Apple via Darwin. Similar with KHTML and Safari, though there Apple has been great about giving back with WebKit. Up until now, at least. Because the software's not properly protected (and here I include LGPL v2), Apple owes us nothing. What good is it if your work only creates a standard for Square One? You want to ensure the future versions enabled by your continues to be an open standard and a force for cough good. Neither of these modes of producing open software, BSD or open after we're done with it, are really "open" in spirit. Both are waiting for conventional modes of production to exploit their resources right back into a closed situation. Bless their hearts. Labels: android, ethics, F/free, Google, hats of money, open posted by ruffin at 3/31/2011 11:12:00 PM

<< Older \| Newer >>