Hardware Rants 1: An Open Future

I keep going back to this (probably ignorant, and stupid) idealization that we are still wasting our time on ancient technology. We still use tar. But this is not about software, it is about hardware.

x86 is already approaching its 30th birthday, and it was never a well designed beast to begin with. Itanium was meant to replace it, and I wish it did, but today we don't have that luxury. I think in most ways Itanium failed because it didn't innovate enough.

There is this massive disconnect in consumer electronics. Everyone does things their own way - custom silicon from the ground up, mostly because the free software ideology has never translated into a free hardware one. There is literally no modern transistor based machine fabricated with a modern process that is also open source. Which is the whole problem, because if being open gimps your ability to function, you lose the benefits.

I have been thinking in recent months about, architecturally, how to tackle this. We are still building on all these legacy proprietary monstrosities, so if we toss all that out for a moment and tackle the parts on their own, we might be able to come to some reasonable conclusions about where to go from here.

First, firmware. You need to start with something. In hardware terms, you have ROM you payload into a cpu, and it goes from there. I think one principle to take to heart in future innovations in the computer space is the ability to package all the tech together in one die. Modern Intel CPUs, for example, have the entire northbridge that ten years ago was its own discrete circuitry onboard. I don't see any reason a newer architecture could not go further with this - having a real system on a chip is hugely advantageous, because it lets you make assumptions.

What would we want on a SOC? Bandwidth channels to external interfaces (I'll get to that), a firmware, something to signal the chip to start and stop, local memory (that may one day simply be enough for most systems) to use before attaching external memory, voltage regulation, and processing "space". I say space because that can include branch predictors, cache, fpus, simd core arrays, or generic pipelined cores. I'd call it core soup, though, because you go beyond AMD's HSA and just treat everything as a first class processor. 

Which I think is really important. We are still developing graphics hardware with each generation having a (usually) proprietary microcode that is generated by (usually) proprietary drivers on the cpu side. That is so bad it hurts.

I really want to talk about interconnects, though. Modern systems are a hodge podge of disparate technologies -  legacy IDE, PCI, serial, and parallel. System specific inter-processor interconnects like QPI. Memory address interfaces like DMI. PCI Express, which has done good in becoming a pretty standard transport interface - it is included in Thunderbolt, for example. Sata and SAS, and don't get me started on how I have no idea how we got into this mess where enterprise uses a different hard disk interface from the consumer space. Or why SATA still requires dedicated power.

In truth, though, all these interfaces are just trade offs along a few spectrum:

• Bandwidth, where you need wider busses and increased synchronization mechanisms or timing control to regulate it, and you almost always are frequency limited already and need to deliver more bandwidth via parallel interfaces.
• Latency, which is the difference between real time transports and packet based ones.
• Distance, when you have cabling traveling meters rather than milimeters, that needs to be flexible, you can't send as high frequency or low jitter signaling as you can on a pcb.
• Interface, where SATA has protocol operators described as electric signals, DMI is just direct processor based hardware to address a numeric node in a memory array. The later is not portable, but the former is.

The modern problem is we have all these interfaces centered around the first three, when all we really should be discretizing is the last one. Thirty years ago manual clocking or bus rate timings were a real issue, but today dynamic frequency and timing has crept into our processors like a child's plaything, but our interfaces never take advantage of that tech. Mainly because they are old.

In principle, what we really need are the following interfaces to almost any computer:

• High bandwidth, low latency interconnect between central system components (memory, other processors, graphics accelerators, local storage)
• Low bandwidth, high jitter tolerance, peripheral interconnect to peripherals that don't demand large bandwidth needs, that minimizes latency.

In theory, you could have one negotiation API for all hardware on any interface, and communicate to it with its choice protocol. It is all electrons on copper anyway, right? We can adopt the PCI worlds concept of lanes here - you have bandwidth lanes off the CPU nodes, and those lanes can be linked to memory, other processors, graphics accelerators, local storage, etc. You make trade offs - less local devices need to run at lower frequencies with more spectrum spread, sacrificing bandwidth for transmit distance. All this could be done by some basic negotiation protocol - the board itself has rom sectors describing each bus's locality, and the rated speeds and lanes for each device.

The serial version is just a single lane, with the same semantics. Rather than have addressing protocols at the controller level, you can have them on the devices and have communication negotiation with the host.

Each lane would have power delivery - probably on the order of 5v 1.1a per lane for 5.5w pull each, so a 30 lane gpu could pull 165w before it needs external power, or an ssd could use 5.5. I could imagine a justification here for having a higher power variant, or just having power tuning on the chipset (which is what we are going for, after all) running off 12v.

Speaking of voltage, this is an area I am just not involved in, but I'd definitely look into depreciating the 3.3 / 5 / 12 volt rails for one common carrier DC voltage that the board itself can distribute appropriately. And getting rid of 24pin connectors. Those things are so stupidly huge.

You would want internal and external variants of these interfaces - though I'd imagine you could just stick the same connectors in each, really, like esata. You would want to include some kind of mounting mechanism for heavy equipment, though.

And the most important policy in all this is that such a system would need to be open. Open standards, open consortium run technology. No patents, open design documentation - at least in the reference implementation.

As an aside, every standards organization that doesn't maintain a reference implementation is lazy. Looking at you, Khronos group. Adopt Mesa, and if it isn't matching your feature bulletins than you might want to slow down pushing the envelope.

As usual, I'm interested in this goodness. If you have money and want to pay me to work on this full time, contact me via the usual channels. I got some passion here I'd need to spend a year draining to the bone to get out of my system.

Software Rants 18: Things to do in KDE for 2014

So it has been a year and I'm still a KDE fanboy. Qt is a great toolkit that needs way more adoption, and QML fixes any gripes I had with c++ widgets. I'm still of the opinion a top priority needs to move the entire qt / kde codebase back towards utilizing the STL, but honestly I can't blame anyone involved for not wanting to try to port tens of millions of lines of code to a new language version, especially when that would prompt a lot of architectural changes (smart pointers, atomics, std::thread, lambdas, constexprs).

My biggest issue is always finding something to do that isn't overwhelming. Today I had an idea - I use btrfs, I was going to write a script to automate my snapshots. After a few minutes in bash, I found instructions to write an EOF to sudo, and gaged a bit, then went to Python. And then I'm thinking "why don't I throw a gui on this and make it official"?

My natural tendency is to move sysadmin features into a KCM module, but if I were to do that I would want to use frameworks 5 and write it in qml, which isn't quite mature yet. Principally I'd be writing code I couldn't use myself on my own system, which is a bit of a no-no, since it would be such a short project.

So I want to go over everything I think could help KDE in 2014, in terms of bug fixes and features, assuming current trajectories place a frameworks 5 release around June and the entire KDE ecosystem switching over sometime in early 2015.

• Menu-in-titlebar : Currently, there is a library called appmenu that allows you to put application menus in an icon in the title bar. This is good, but the next iteration is to place the full menu in the title - personally, I'd implement this as an extension of appmenu, so that on sufficiently small windows the menu collapses into the app icon. When the titlebar isn't big enough to filt the whole menu, you have a minimum title size (determined by study, whatever is the minimum set of characters to uniquely identify a window in, say, two standard deviations of all windows) and fill the rest of the bar as much as possible with the menu, from the left to right. If the whole menu fits, the title can either right-align all the time, or center in the remaining space. If the whole menu doesn't fit, you have two arrows on eithe end to scroll the bar, which also works as a flickable and with the mousewheel. If you invoke a menu through keybind, such as the file menu, it would animate the slide to bring it into the frame if it isn't already visible. I would also imagine other controls you could integrate into a titlebar, such as per-window brightness, contrast, volume, pitch, and base.
• Window / display sharing : Miracast is supposed to show up in Mesa this year, but as a technology it is woefully lacking. We should also see Daala released this year - hopefully taking the video codec world by storm. Whenever that happens an evaluation will be needed on open codecs for one that can do streaming with low latency and good compression like h264 streaming seen in Miracast, Shield, OnLive, etc. This technology needs to be standardized beyond KDE, so it can be used as a window share protocol for Wayland for network transport, for use in RDP to help with its bandwidth constraints, and open video conferencing. WebRTC and Jingle are both projects involved in this domain, so whatever matures out of there could be wide-band adopted as window, screen, and livestreaming across the desktop. An intuitive implementation could be a killer feature for years.
• Timeline : Rosa has an implementation of an activity timeline already in release, and should see adoption in the broader ecosystem. A lot of features from Rosa should probably go mainline kde, since they all seem well integrated with Plasma Active and Desktop.
• When I create a new folder, Dolphin shouldn't pop up a dialog, it should make the folder while I enter a name field. This is actually what happens with the qt files dialog.
• Rekonq : I really want to use rekonq. Probably yesterday. The footprint is much lower, it has a super fast rendering engine, and it integrates so well into the desktop. My problems with it all stem from core features of Firefox I just need available, and its its implementation of an addon API to mimic Chromes so it can use all of their apps will be the deal breaker. The other aspect is syncing - it currently only does Chrome bookmarks syncing. If it can act as a Chrome browser for syncing purposes, it would be set.
• Deep screen recording integration : KSnapshot should at least have an option to record to vp8 or ogv with a start / stop record button that is keybindable. Since opengl recording requires injection, dedicated programs suffice, but having one of those as well would be nice. In theory, though, you would want to expand KSnapshot's sharing features to send images to others, and to broadcast live video or send the recorded footage. I'd definitely like to tackle this problem domain this year.
• An active solution to small buttons : Plasma Active has one problem right now, which is that most buttons are too small. I expect that in kf5 the theming engine will be reworked enough to easily specify a scaling factor on all interactables (probably through some deep qt integration), rather than just individual elements, so the desktop can have its traditional metaphor that can elegantly scale down to the mobile form factor with one slider.
• Distributed cloud accounts : It would be infeasible to have a completely free desktop like KDE provide per-user networked accounts with a verbose sharing policy with akonadi, plus all your per-app settings, plus your saved passwords, etc. An alternative solution is to effectively combine bittorrent sync and wallet passphrases - run a daemon that seeds and shares wallet data with the swarm, with a few orders of duplication and information sharing (ie, each account is duped in fractional parts across the whole network, and you can rebuild your own complete network account database, which has that access logged in case someone is trying to brute force you. Plus, every IP could have fail-2-ban on a swarm scale, so anyone trying to brute force  pull all accounts would have their ip ranges blocked quickly for short lockouts but ones that make raiding the entire swarm infeasible. Because if you had this system, you could have a secure share of your passwords, bookmarks, application preferences, you can share files in your kde cache, etc. It would require some kind of usage limit so someone doesn't just dump data into the cloud and overwhelm it, but it should be able to hold at least voice mails and several photos or short video clips.

I'll add to this list as I think of new things, but I hope this is a bright year for the KDE project, and that I can find the time to crank out some of these ideas. First I want to finish the cadeques book and read the kf5 documentation in progress.

Display overclocking with XRandr

As the trends shift and more enthusiast class users start considering Linux, it is important you supply them with the tools to do all the push-it-to-the-limit overtuning effects they had available under Windows.

Monitor overclocking isn't a well documented art, especially since it can literally break the display, in a way reminiscent of 90's AMD processors literally melting their sockets. This isn't the coddled down overclocking of todays desktops, where pushing things too far just results in an unexpected reboot and need to tweak expectations lower. Try setting your monitors refresh rate to twice or more what it is rated and have fun with a dead panel.

That doesn't mean you can't overclock soundly. Trying to double your refresh rate is like trying to run an i7 at 6ghz with the stock cooler. Instead, look for incremental increases in performance like any other overclock, and hold it back from the literal edge of stability a bit so your screen lasts longer than a month.

Under Windows, as usual, the sizable install base has produced graphical tools to set refresh rates. And yet again, Linux proves its technological superiority by not requiring any such tool, xrandr has all the facilities you need to create custom display modes.

So yeah, we are using the cli here, but this is one situation I'll defend this usage - one, it requires you to know what the hell you are doing, and two it is integrated right into the display manager itself and is literally a few bash lines, and if you get a stable OC you can just add it to your xprofile or autostart scripts. In this example I'm taking a 60hz screen to 65 - start here, at the least (or on a 30hz panel at like 33), and increment up until you start seeing graphical errors or glitches. Good tests for graphical errors are fast paced rapid scene changes in 3d games, plus some repetitious pattern (to gauge burn-in), plus anything that rapidly fluctuates the subpixels color intensity, I just use a gif of rapid color flicker at 48 fps.

First, we use the cvt, provided by xorg, which stands for coordinated video timings from VESA. It generates the modelines for our desired new display profile.

cvt 1920 1080 65

Modeline "1920x1080_65.00"  188.00  1920 2048 2248 2576  1080 1083 1088 1124 -hsync +vsync

We get back this Modeline, which we will add to xrandr - note changing the quoted part just changes what we name this mode, so you can name it "oc" or "65" and be fine, since xrandr by default populates modes by resolution (ie, 1920x1080).

xrandr --newmode "1920x1080_65.00" 188.00 1920 2048 2248 2576 1080 1083 1088 1124 -hsync +vsync

So now we have a registered mode, we need to add it as a valid mode to our specific screen - running xrandr without arguments prints the state of all the display outs, find your choice screen and replace HDMI1 here with whatever it got named.

xrandr --verbose --addmode HDMI1 "1920x1080_65.00"

Then you need to actually set the mode. If after running this you see obvious glitches, revert quickly before your display is damaged. Good news is that on many panels, going ludicrously out of refresh bounds will just get you out of range errors on the display or in your xorg log (ie, my Asus IPS pannel probably is only rated for hdmi 1.2, so it can't go beyond 75hz refresh).

xrandr --output HDMI1 --mode "1920x1080_65.00"

If you encounter errors, remember you will probably need to specify the rate as well for your default modes, since most panels present multiple refresh rates and omitting may not pick the highest assumed rate.

xrandr --output HDMI1 --mode 1920x1080 --rate 60

But if it works, congratulations, you overclocked your monitor. You will have to add all the xrandr lines into an init script to run every boot, since it is a non-standard mode. I'm definitely going to be prioritizing good OC displays in the future, you can save some buck on that 120hz premium. I'd love to get an early 4k display that can support getting an OC to 90hz, since Displayport 1.3 can easily handle that.

AUR Packages that should really end up in official repos!

What a strange blog topic, but something I'd like to document since I really think the only failing of Arch is the rate of official adoption of aur packages.

As a preface, I won't mention anything proprietary, because most of those packages can only be in the AUR due to the legality of distribution. Also, why would the Arch support infrastructure bear the burden of distributing other peoples proprietary blob? Though they do have some proprietary software in their repos, such as Steam and Flash, I'm not going to harp on anyone for not serving up server space for other peoples binaries.

First group - games. Plenty of games and game engines are already in community, so any foss game engine has no excuse (assuming it isn't brand new) for not getting adopted.

• darkplaces (quake engine)
• eduke32 + eduke32-dukeplus (duke3d engine)
• freedoom (entirely free game assets for doom!)
• gzdoom (doom engine)
• hexen2 (hammer of thyrion)
• openarena (foss quake 3 fork)
• zandronum (foss doom engine with multiplayer)

And the second group is a plethora of KDE and qt apps and documentation that all seem to have 100+ votes but are still not in the main repos:

• kcm-ufw
• kcmsystemd
• kde-thumbnailer-epub
• kdeartwork-sounds
• kdeplasma-applets-networkmanagement
• kdeplasma-applets-starfield-wallpaper
• kdeplasma-applets-veromix
• skanlite
• qt5-examples
• qt5-jsbackend

I would say that a lot of these aformentioned packages all include a lot of data files like models, textures, and sounds that would take up huge amounts of server space - and I'd completely understand not including that in the main repos, if it was not for the fact games like 0 A.D. and Xonotic have their data hosted in official repos.

I also get a lot of the second set of packages I mention require the input of the original authors who may be MIA. That would explain a lot of it. And maybe some of the first group just outright said no to official Arch packaging, who knows.

I just think moving forward Arch will need to consider ramping up the process of pulling the most popular and longest running AUR packages that aren't proprietary into offical repos. My impression is that it doesn't happen nearly enough, and that can lead to overdependence on the aur when pacman and its repository system works so well. Being constrained to pkgbuilding everything you use isn't the right answer, but neither is a laissez faire avenue to getting anything into official repos on a whim.

Software Rants 17: Two Project Ideas built around optional subscriptions

With the debacle about Youtube switching to Google Plus comments and effectively ruining conversations on the site, plus the recent announcement of Warlords of Draenor, I want to get my own ideas about how to create two completely independent systems but have them using the same business model.

I'd love to work on one of these. I think both of them could change the world for the better in big ways, so in the absurdly unlikely event someone reading this has the capital to fund this stuff, contact me.

First, the premise - modern business transaction based business models are broken, especially on the Internet - you are either bound at the hip to advertisers (Youtube), abusing the skinner box and micropayments (mobile gaming), or don't actually make money (Tumblr, Twitter). In principle, you won't get people to pay to see or use your site directly (a good thing, your marginal costs of usage are nothing so the marginal cost to use should be nothing). Some people are having success on Kickstater and its ilk, however that model is proving itself weak in the capacity to fund a long-running project. IE, even after collecting your 1000% of asking price in donations, you still run out of money because you are trying to use crowd funding as venture capital. To make matters worse, even though upwards of millions of people directly paid you to create a product whom you are not beholden to at all in that they don't own your company or have any investment return prospects besides the product you are creating, you often expect to abuse copyright to make proceeds off your product after it is finished, ie, selling a kickstarted game on Steam.

I understand why that happens - if you tried to actually pay the entire development cost of a modern gaming title, it would not be in the budget of a million or two bucks but maybe ten to twenty. The most successful campaigns barely scrape 10 million, and those are hardware projects.

But I think the problem there is the payment window. You make a month long campaign and then go dark after that to additional funding avenues, at least in public - you might use the kickstarters success to pitch to investors, but not the general public.

Likewise, the average joe content creator, be it indie games, music, video, art, etc - are all shackled to either comissions for their work on a per user basis, or advertising giant Google pretty much exclusively. Many webcomics use non-adsense advertising, but that almost never breaks even with the time investment.

I see the same solution to both problems - instead of asking for money once, or targeting individual contributors, or being beholden to advertising as a surrogate revenue source - you constantly collect from a broad pool of users in variable amount.

Media Platform built around micropayment subscriptions

Today, a lot of youtuber's are having success with subbable and patreon, services that allow your audience to pay you on a monthly or per-content basis a fixed amount they set. Twitch also uses a similar system with its subscriptions - $5 a month, but that is very limited in scope compared to what I'm going to talk about.

The idea is that a very small fraction of your audience will often have the disposable funds to pay you for your work and will do so to keep you producing. As long as you have enough income to justify your content creation, the number of people "freeloading" off the pervasive information penetration of the Internet are just a catalyst to attract more voluntary subscriptions. It is also important to let people volunteer as much money, as often or as infrequently as they like, because the amount of money someone might offer can vary tremendously.

You can also integrate "prizes" into such a system for one time or recurring payments. IE, every $20 you get a comission from an artist, or every $50 gets you a song or you could pay $1000 for a 30 second animation. 

Rather than focus a platform on one type of media (video, audio, games, art, text) I'd propose a model where you have users, who have feeds of created content of any form - with means to batch consume a users content of a type, with the ability to tag or categorize it as you wish into your own personal collections - with reddit-style comments and "forums".

As a result, each user is their own effective "subreddit" of posts they create, and only they can submit to their own personal page - you would have three sorting options, rating, max rating, and date. Rating behaves like reddit or google+ comments that degrade over time so newer popular content will rise to the top. Max rating is raw voting totals, and date is by oldest or newest.

You can also have public forums in this system that can behave just like normal subreddits on reddit - a user creates it by unique name, and can control its usage by assigning moderators, etc. They behave exactly like user pages, which also allow you to password lock them or make individual entries private or password protected.

Your subscriptions feed is just like reddits home page, the sum of all the users and general groups you follow. You would also be able to create, submit, or share meta-posts and meta-groups - colections of users or forums as one forum or collections of submissions as a single submission - that imitates music albums, tv show seasons, photo albums, aka, playlists and meta-reddits.

This site would use the minimal of advertising, potentially none - the funding source is through user content. Depending on some beta testing, users might immediately be able to accept payments or might need a certain submission comment threshold to do so. Users could hide content pages to subscribers or donors only, but one of the principles of this kind of site would be that in the TOS all content posted must be under a permissive license, with the most permissive license being the default creative commons license, with the default being creative commons attribution share-alike.

The goal is to let content uploaded be distributed by users - in effect, to minimize costs, I would propose using an optional desktop client for computers to share the bandwidth load and seed content to reduce server costs using the bittorrent protocol, so that as users view content they cache it locally and seed it. Such content would have expirations - ie, the user could set a maximum local storage limit, and whenever that limit is reached the oldest content not seeded is purged. Content uploaded should not be able to be restricted back into proprietary non-open usage, but we would want to mandate attribution. 

I would need a more thorough legal evaluation of licenses for this purpose - because I'm not sure if the CC-A-SA license guarantees derivative works need to be openly redistributable.

Back to funding - I'm open to traditional dollar based funding models, but I imagine using bitcoin as the primary funding tool would help the platform evolve. We wouldn't act as an exchange, but I would definitely integrate with coinbase at the least and possibly other exchanges especially for foreigners in other countries to have ways to move fiat into btc for use on this site. Each user would get an account-bound wallet we maintain, and can move funds in and out using web tools and can deposit to a btc address we give them. 

Like I said, we could also have fiat money accounts and the like, but that gets very complicated. It would probably use paypal, amazon payments, or some other authority that has the legal power to deal in that tremendous mess. Users would get to choose varying ways to pay for works or user content creation - you can donate on a timed basis, ie, daily, weekly, monthly, annually. You could donate per-content, and can pick by tags, a title filter, content type, or all content produced with daily, weekly, monthly, annual limits. You can do a one-time donation of any amount, and like I said earlier the content creator can have a listed set of donor benefits that are either recurring or one time, with either per-user or in general limits on availability.

To help enable this, nothing stops a later iteration of this product finding a, say, t-shirt company , and offering donor incentive shirt designs on-site with seamless integration. IE, like this animation by insert-X-author? The donate button is right on the video, and the shirt is one of the choices. If you have money on site it is literally a one-click buy assuming your shipping info is already on record, otherwise you have to enter that. If you have no on-site money, we can provide third party payment services including bitpay. Users would have an option to make their site btc address (or a personal one they want to list) public so you can donate from alternative btc services.

I want to mention I'm not a big fan of the depreciating nature of bitcoin as an exchange currency, and if any competitive inflating cryptobuck came along I'd want to be an early adopter. People will more willingly donate and exchange on and off site if their money is becoming worth less over time.

As with any good site, it would require a comprehensive and effective search engine for content - recommendations, filtered searches by content type, tag, user type, user name, rating, etc. I don't think one sentence, however, is sufficient to detail the complexity of a well implemented search engine, so we might depend on something like duckduckgo on the backend.

It would all, of course, be completely FOSS, and the revenue is from transaction fees. Since you would expect the site to be operating with huge amounts of money transfer in bitcoin, you could use a very low transaction fee of like 1%.

This way the success of users means the success of the site. You have to leverage the convenience of on-site funding over using an off-site service like patreon or subbable, and there would be a balancing act - attracting content producers with favorable margins in the first place while understanding the convenience factor of on-site payments can let us put margins above what other such services get from transactions of this nature.

2. Collaberative MMO

The MMO space is horribly stagnant. I have an idea for a potential organic game and business model based off the media site above - in theory, nothing prevents the same code base being used or it even being within one company with two interacting teams. 

I won't go into details on game mechanics here, because I've talked about how I'd want to design this theoretical MMO in other posts on this blog. The series is kind of on hiatus, because I keep going back to software rants whenever I want to talk game design, but I'll work on that.

The principle issue with most modern MMO games is content - the investment to create an initial set, the habits of making leveling content and group content independently, the inability to release it rapidly enough to keep up with player hunger, especially in monthly subscription games, and the habit of invalidating past work.

To address budgetary concerns this game would not have a long development time. In traditional MMO terms, if we wanted the initial product to be 60 levels, we might release with only 5 levels worth of zones and content done. Then as we finish more zones we push them to a beta realm for testing and then live for people to experience, with constant releases of small amounts of content. Since this game would not be subscription based (we will get to that).

The business model is the direct funding of content creation using a reddit like platform - and both users and the business itself can do it. In theory we could make this an entire funding platform independent of this origin MMO, in that a user will submit a content creation proposal, and would set a fixed or variable funding campaign, with pontential donor incentives. This ties back into the media content site, because you use the same backend payment and rewards systems, and that site already can enable a user to create a funding project for eventual creations rather than donations on a recurring basis.

What we do here is use that system on a macroscopic scale in the context of an MMO - users can create submissions on a "requests" forum, where top ranked posts can be reviewed for potential funding projects, and the development house itself will create independent listings of different projects to fund. What gets funded gets made, so users can pick and chose the content they want to be developed.

You might see, say, in WoW terms again, a new raid for 100k, a new dungeon for 5k, a new zone for 50k, a class review for 10k, a new specialization for 30k, new monster models for 15k, new skins for 3k, etc.

You could have donor mounts and perks as well, in the same micropayments system in place in many MMOs now.

The real divider is that this game, like the original site, would be entirely FOSS. All models, all sounds, music, textures, etc - would be under CC attribution sharealike or AGPL3 / GPL3. This lets others, if they want, host their own servers. In the end, as a business - we don't care, because our funding isn't in trying to sell the finished product, but in creating it, and in getting paid to host our own servers. It doesn't affect our bottom line at all for someone to use third party servers, especially because our servers are free and where the new content momentum would be.

Because of the openess, we would also have a forum for user created models, animations, textures, and sound effects - users would upvote them, and by submitting content there you have to approve a TOS that says you give it to us under CC-A-SA or A/GPL3 licenses (the latter if it includes code).

Just like on the media site, we could have game resources in a bittorrent network. The one thing I would like but I don't think it is feasible is having users host their own servers - there is no way to verify the game is unmodified, because the code would be open they could just spoof authentication measures. This means we need to self-host the game servers to avoid cheating.

I think it could be wildly successful and popular - the natural popularity and hunger for content would accelerate funding to enable the development of more content to make the game better and attract new users. Because the model isn't pay to win - it isn't pay for pretty much anything with the exception of any pay-for cosmetics the users fund in the first place - you can expect a huge playerbase with no difficulty actually balancing the game. You could create "hardware" content for the extreme raider and casual content for the 1 hour a day full time mom because both can contribute to funding whatever they want to see in the game. It is literally putting your money where your mouth is.

Since this would be a company, we would be able to deny feature requests and we are the only ones to establish the funding campaigns for content added to the final game.

Another way to entice user participation would be a model where, once a model or sound or such is produced and verified working and wasn't pre-funded kickstarter style, we could have a funding campaign to pay the user creator that gets the asset put in the game.

Of course, the user could skip such a funding goal if they just want to give away their work. But it is an alternate way to get them paid to create, without the risk of not getting what you asked for.

I want to also mention this need not be an MMO - you could create any game this way. Make a single player FPS with one level for free, and have such infrastructure in place to incentivize the funding of additional content. You could do this with almost any game, it just seems an MMO would work best due to its inherent networked nature and the lack of a model to make an open MMO.

In general, I'd want to found a business to implement both ideas under one codebase and roof - they tie together very well. Such a platform could enable an entire generation of media creation and sharing, and b y enforcing open license principles it could keep a generation of media free while paying content creators.

If anyone reads this and finds it interesting and would go so far as to be interested in trying to make either a reality, contact me! (yeah right)

Software Rants 16: Binary Firmware and Trade Secrets

Almost a year ago, I built my grandparents a new pc with an a10-5800k processor, on the pretense that AMD is hurting and they contribute a foss driver, they deserve some support.

A year later, my grandparents are still regularly using catalyst on their Suse install, because whenever I plug in their living room tv via hdmi, the driver fails and I get two black screens, or the tv has color bars on it until I mode set the normal desktop monitor, and then we are back to all black.

Looking forward, in future computer builds, I am looking at parts not for features or performance or reliability but I look for parts that aren't binary blobs doing whatever the hell they want with no way to audit their behavior, in kernel space.

The problem is there is nobody on my side in this. Intel's chipsets are completely proprietary, with no open source support for them at all. Their processors are obfuscated trade secrets with opcodes to payload encrypted firmware blobs to modify the microcode to do whatever the hell they want at runtime, and their network controllers have binary blob firmware that might be broadcasting who knows what.

Sadly, though, they are the only vendor with an actual free gpu driver. No firmware blobs, no bullshit, relatively open specification. They don't support gallium, but really, thats their call. They waste their time, and everyone elses time, not using one stack, but at least they are trying.

However, on the other side of the fence, you have AMD - they participate in coreboot, their cpus are still trade secret proprietary mess but not as bad as Intel, but they use prorprietary firmware blobs with their gpus, and thus you can't reimplement their driver without reverse engineering that crap.

When it comes to processors in general, they are all bullshit trade secret messes. There is not one open spec cpu, even the Leeong chip from China licenses MIPS. So if you are stuck on some proprietary garbage, you might as well use the x86 chips, since at least Intel isn't profiteering off of IP law with their cpu design (AMD's contract with them is pennies on the chips they make).

So why can't I buy an AMD chipset with an Intel APU? I want open firmware across the board, because I want an open system where I can look at exactly how everything works and tweak it to my desire. But there is no way to build a system without someone restricting my freedom with my own hardware, and it sucks.

Meanwhile, Nvidia is off in la-la land, their proprietary blob graphics cards can blow me, but Nouveau is more open than AMD chips, since the reverse engineered firmware is foss! And they have open source drivers for their Tegra APUs, and they just license ARM cores.

I hope they consider making a Tegra 5+ based NUC, because I'd be interested in that. Kepler graphics on a foss driver + firmware, on a chipset with coreboot, and arm v8 cores I could live with. But right now all our options suck. If I had connections, i definitely have the desire, I'd make an open hardware company. But you wouldn't want to found it in the US, because patent and trademark trolling would crush you before you got off the ground.

The Future of the Computing Platform

I'm in love with NUCs. Even though I usually despise the Intel marketing terminology (because they always trademark it, and because it usually sounds silly like ultrabook) in this case they nailed it on the head.

Firstly, the desktop. Or more specifically, I'd call this the class without an internal battery, because size is the topic. ATX and even micro ATX mainboards are now complete overkill. The only reason they even exist is exclusively graphics cards - and only the most insane users run multi-card configurations (note - the difficulty with multi card configurations is probably on the foundation of how hackneyed the entire platform is, but ranting about hardware architecture is something I have already done, and something I will probably do again in the future. Regardless, if you discount the graphics card slots, what can you really put in a pci slot anymore? Let's list them:

•  Discrete Audio Cards: Only for audiophiles. And if you care, just get a mainboard with beefier integrated audio. Asus even has a z87 board with a discete class audio solution embedded into the board proper. You don't need a coprocessor because pcm to onboard analog signaling is dirt cheap, and you often end up using digital audio out anyway in which case you can often just transport an aac or the pcm stream anyway. Note: spdif fuckers, get opus support in digital audio standards yesterday and junk all that other crap.
•  TV Tuner Cards: One, tv is dying, two, there are usb tuners. When I built my grandparents rig I got them an internal pci tuner under the assumption it gets better quality. In hind sight, probably not. On the first point, broadcast television is already going the way of the Dodo and I would never build a new system around converting dvb-t or a signals to mpeg2.
•  Raid Cards: The integrated raid controllers on most mid range motherboards are sufficient for 3 - 5 disk raid 5, and really, if you are even thinking of consumer raid this is where you are looking. Servers already have entirely different pcb form factors anyway, so you can keep dedicated pcie raid cards there just fine. Additionally, raid 0 with ssds has no performance improvement (maybe sata express will change that in a higher per channel bandwidth world) but I doubt it, because principally ssds already have radical random reads and writes. This means you might as well raid 1 with ssds rather than raid 5, and SSDs aren't like mechanical disks where one memory sector going bad kills the drive. You just don't need that redundancy class even in a homebrew home server. And again, if you do, the integrated raid is often good enough.
•  PCIE SSDs: These have a claim to fame in how sata 6gbps is at its limit and the only way to get more bandwidth in consumer hardware right now is pci express lanes. However, the interconnect isn't really targeting block devices, and the big 16x slots are overkill for 1GB/s sequential read ssds.
•  Network Switches: This is one that is harder to replace because a four way splitter has peak bandwidth requirements of 4gb/s. It isn't a block device so you can't stick it on sata 6gbps, even though that would make sense. Though, again, who is building a system with a network switch? I intend to, but I'm weird. Niche markets shouldn't dictate consumer standards.
•  Port Expansion: ie, more usb3 ports on a hub card. Like integrated audio, this should also be integrated to satisfatory levels. If you need more, you are a niche.

 Overall, there are just not many cases where 99% of people would want an expansion card *besides* for a gpu.  Likewise, this isn't 2005 anymore, and you aren't likely to upgrade your processor but keep the same motherboard. You pack a processor, mobo, and set of ram into a system, and leave it like that. You might get more ram (ie, a second set if you only bought one) but even that is rare, and you could have just bought double capacity from the start.

I predict a new world of form factors - for the classical enthusiast class, a small mitx size board taking up to 2 sodimm slots and a socket in the 20 - 30mm range rather than 35 - 50 (since large dies are overheating anyway), mpcie and msata completely replacing standard pcie slots, and 2.5" mechanical drives becoming standard under-the-board connected disks. The only exception is gpus, which won't be able to easily migrate from high bandwidth 16x lanes with space for heatsinks and dedicated fans running on 12v to pcie 1x at 3.3v with no fan options unless the device makes room. But APUs are now proving themselves very capable, and unified memory is a huge benefit for simpler implementation. And all 3 big players have apus (Nvidias are just ARM based).

 Even smaller than that, I expect soldered boards of combined pcb + cpu + memory to become common, since you rarely upgrade any of those parts, and becuse all 3 are always mandatory in any build. It enables smaller units when you don't need to worry about standard ports and sockets.

The enthusiast market won't go away, but likewise these big behemoth motherboards are also dinosaurs. There are connectors for these smaller form factors, and NUCs are paving the way, although the combination of case and pcb isn't great. What you really want is a case and a motherboard standard with a simpler power connection architecture (so you could have an external or internal power brick). But they are the future, and it will be small.

Software Rants 15: The Window Tree

I've had a barrel of fun (sarcasm) with X recently, involving multi-seat, multi-head, multi-gpu - just in general, multiples of things you can have multiples of, but most of the time don't, so the implementations of such things in X are lacking at best, utterly broken at worst.

I also am becoming quite frustrated with opensuse, trying to fix varous graphical and interface glitches to get a working mutlihead system for my grandparents.

But I look towards Wayland, and while I appreciate the slimming, I have to be worried when thing like minimizing, input, and network transport are hacks on top of a 1.0 core that already happened. It reeks of a repeat of the X behavior that lead to the mess we have now.

So I want to talk about how I, a random user with no experience in writing a display protocol or server, would implement a more modern incarnation.

First, is to identify the parts of the system involved. This might have been a shortcoming in Wayland - the necessary parts were not carved out in advance, so they needed to be tacked on after the fact. You can represent this theoretical system as an hourglass, with two trees on either side of a central management framework. In Linux terms, this would be through DRI and mode setting, but the principle is that you must communicate virtual concepts like desktops and windows (and more) into physical devices, and do so in a fluid, organic, interoperable, hotpluggable fashion. This might be one of Waylands greatest weaknesses, in how its construction doesn't lend itself to using an arbitrary protocol as a display pipe.

You would have a collection of display sinks - physical screens, first and foremost, but also projectors, recorders, a remote display server, cameras to record from, etc. They are all presented as screens - you can read a screen with the necessary permissions (through the display server). To write a screen, you must also use the display server. You can orient these screens in a miriad of ways - disjoint desktops, running in seperate sessions - you might have disparate servers, with each one managing seperate displays, and inter-server display connectivity is achieved through either the general wide-band network transport (rdp, udp, etc) or over a lower latency / overhead local interconnect (dbus). Servers claim ownership of the displays they manage, and are thus a lower level implementation of this technology than a userspace server like X or even the partial kernel implemented wayland - it supplants the need for redunant display stacks, where right now virtual terminals are not managed by a display server, but by the kernel itself, in this implementation virtual terminals would just be another possible desktop to provide by the display server.

Obviously, this server needs EGL and hardware acceleration where possible, or use llvmpipe. The system needs to target maximal acceleration when available, account for disparate compute resources, and not assume the state of its executation environment at all - this means you could have variable numbers of processors, with heterogeneous compute performance, bandwidth, latency, an arbitrary number of (hot pluggable) acceleration devices (accessable through DRI or gl) that may, or may not, be capable of symmetric bulk processing of workloads. Multiple devices can't assumed to be clones, and while you should correlate and optimize for displays made available through certain acceleration devices (think pci gpus with display outs vs the onboard outs vs usb converters vs a laptop where the outs are bridged vs a server where the outs are on another host) you need to be open to accelerate in one place and output in another, as long as it is the most optimal utiliziation of resources.

So this isn't actually a display server at all, it is the abolition of age old assumptions about the state of an operating computer system that prevent the advancement of the overall state of kernel managed graphics. Tangentially, this relates to my Altimit conceptualizations - in my idealized merged firmware / os model where drivers are shared and not needlessly replicated between firmware and payload, the firmware would initialize the core components of this display server model and use a standardized minimum set of accelerated apis to present the booting environment on all available output displays (you wouldn't see network ones until you could initialize that whole stack, for example). Once the payload is done, the os can reallocate displays according to saved preferences. But the same server would be running all the way through - using the same acceleration drivers, same output protocols, same memory mapping or the port sinks.

Sadly, we aren't there yet, so we can't get that kind of unified video (or unified everything as the general case). Instead, we look towards what we can do with what we have now - we can accept that the firmware will use its own world of display management and refactor our world  (the kernel and beyond world) to use one single stack for everything.

So once you have this server running, you need to correlate virtual desktops and terminals to displays. The traditional TTY model is a good analogy here - when the server starts (as a part of the kernel) it would intiialize a configured number of VTs allocated to displays in a configured way (ie, tty1 -> screen0, tty2 -> screen1 which clones to remote screen rscreen3, tty4 -> recorder0 which captures the output, tty5 -> screen2 which clones to recorder1, etc). tty6 could be unassociated, and on screen0, with its associated input device keyboard, you could switch terminals like you do now. You could have the same terminal opened on multiple displays, where instead of having a display side clone, you have a window side clone (ie, not all outputs to, say, screen0 and 1 are cloned, but tty15 outputs to both of them as simultaneous display sinking).

A window manager would start and register itself with the server (probably over dbus) as a full screen application and request either the default screen or a specific screen - recalling that screens need not be physical, but could also be virtual, as is the case in network transport or multidisplay desktops. It is provided information about the screen it is rendering to, such as the size, the DPI, brightness, contrast, refresh, etc - with some of these optionally configurable over the protocol. This window manager may also request the ability to see or write to other screens beyond its immediate parent, and the server can manage access permissions accordingly per application.

On that desktop (which to the server is a window, occupying a screen as a "full screen controlling application" akin to most implementations of a full screen application, and whenever it spawns new windowed processes, it allocates them as its own child windows. You get a tree of windows, starting with a root full screen application, which is bound to displays (singular or plural) to render to. It could also be bound to a null display, or no display at all - in the former, you render to nothing, in the latter, you enter a freeze state where you suspend the entire window tree under the assumption you will rebind that application later.

In this sense, a program running in full screen on a display, and a desktop window manager, are acting the same way - they are spawned, communicate with the central server as being a full screen application running on some screen, and assume control. If you run a full screen application from a desktop environment, it might halt the desktop itself, or more likely it moves it to the null screen where it can recognize internally it isn't rendering and thus stop.

I think it would actually require some deeper analysis if you even want an application to be able to unbind from displays at all - additionally, you often have many applications in a minimized state, but you want to give a full screen application ownership of the display it runs on (or do you?) so you would need to create virtual null screens dynamically for any application entering a hidden state.

Permissions, though, are important. You can introduce good security into this model - peers can't view one another, but parents can control their children. You can request information about your parent (be it the server itself, or a window manager) and get information about the screen you are runnning on only with the necessary permissions to do so. Your average application should just care about the virtual window it is given, and support notification of when its window changes (is hidden, resized, closed, or maybe even if it enters a maximized state, or is obscured but still presented). Any window can spawn its own children windows, to a depth and density limit (to prevent a windowed application from assulting the system with forking) set by the parent, which is set by its parent, so on and so forth, to a display manager limit on how much depth and bredth of windows any full screen application may take.

The full screen application paradigm supports traditional application switching in resource constrained environments - when you take a screen from some other full screen application, the display server will usually place it is a suspended state until you finish / close, or a fixed timer limit on your ownership expires (a lot like preemptive multiprocessing with screens) and control is returned. Permissions are server side, and cascade through children, and while they can be diminished, they require first cllass windows with privildge assention to raise them.

You can also bind any other output device to an applications context. If you only want sound playing out of one desktop environment, you can control hardware allocation server side accordingly. Same with inputs - keyboards, mice, touchscreens, motion tracking, etc - can all be treated as input, be it digital keycoding, vector motion, or stream based (like a webcam or udp input), and assigned to whatever window you want, from the display server itself (which delegates all events to all fullscreens). Or you can bind them to a focus, which in the same way you have default screens, you can have a default window according to focus, and delegate events into it (from the application level, it would be managed by the window manager).

You could also present a lot of this functionality through the filesystem - say, sys/wm, where screens/ can correspond to the physical and virtual screens in use (similar to hard drives, or network transports, or audio sinks), and sys/wm/displays where the fullscreen parents reside, such as displays/kwin, or displays/doomsday, or displays/openbox. These are simultaneously writable as parents and browasable as directories of their own children windows, assuming adequete permissions in the browser. You could write to another window to communicate with it over the protocol, or you could write to your own window as if writing to your framebuffer object. Since the protocols initial state is always to commune with ones direct parent, you can request permissions to view, read, or write your peers, corresponding to knowing their existence, viewing their state, and communicating over the protocol to them. As a solution to the subwindow tearing problem, the server understands movements in parent are recursive to children, such that moving, say, one window 5px means a displacement in all children by 5px, and a corresponding notification to that windowit has moved, and that it has moved due to a parents movement.

The means why which you write your framebuffer are not the display servers problem - you could use egl, or just write the pixels (in a format established at window creation) between the server and the process. Access to acceleration hardware, while visible by the display server, is a seperate permissions model, probably based off the user permissions of the executing process rather than a seperate permissions heirarchy per binary.

In practice, the workflow would be as follows: the system would boot, and udev would resolve all display devices and establish them in /sys/wm/screens. This would include udev network transport displays, usb adapted displays, virtual displays (cloned windows, virtual screens combined from multiple other screens in an established orientation, duplicate outputs to one physical screen as overlays) and devices that are related to screens and visual devices like cameras, or in the future holographics, or even something far out like an imaging protocol to transmit scenes to the brain.

Because output screens are abstracted, the display manager starts after udev's initial resolution pass and uses configuration files to create the defult virtual screens. It doesn't spawn any windowing applications, though.

After this step, virtual terminals can be spawned and assigned screens (usually the default screen, which in the absence of other configuration is just a virtual screen spanning all physical screens that has the various physical properties of the lowest common denominator of feature support amongst displays). In modern analogy, you would probably spawn VTs with tty1 running on vscreen0, and 2-XX in suspend states, ready to do a full screen switch when the display server intercepts certain keycodes from any input device.

Then you could spawn a window manager, like kwin, which would communicate with this display server and do a full screen swap with its own display configuration - by default, it would also claim vscreen0, and swap out tty1 to suspend. It would request all input delegation available, and run its own windows - probably kdm as a window encompassing its entire display, while it internally manages stopping its render loops. It would spawn windows like plasma-desktop, which occupy space on its window frame that it assigns over this standard protocol. plasma-desktop can have elevated permissions to view its peer windows (like kdm) and has lax spawn permissions (so you can create thousands of windows on a desktop with thousands of their own children without hitting any limits). If you run a full screen application from plasma-active, it can request a switch with the display server on the default screen, its current screen, or find out what screens are available (within its per-app permissions) to claim. If it claims kwins screen, kwin would be swapped into a suspend state, which cascades to all its children windows. Maybe it also had permissions and spawned an overlay screen on vscreen0, and forked a seperate full screen application of the form knotify or some such, which would continue running after vscreen0 was taken by another full screen application, and since it has overlay precedence (set in configuration) notifications could pop up on vscreen0 without vblank flipping or tearing server-side.

Wayland is great, but I feel it might not be handling the genericism a next generation display server needs well enough. Its input handling is "what we need" not "what might be necessary" which might prompt its obsolescence one day. I'd rather sacrifice some performance now to cover all our future bases and make a beautiful sensible solution than to optimize for the now case and forsake the future.

Also, I'd like the niche use cases (mirroring of a virtual 1920x1080 60hz display onto a hundred screens as a window, or capturing a webcam as a screen to send over telepathy, or having 3 DEs running on 3 screens with 3 independent focuses and input device associations between touchscsreens, gamepads, keyboards, mice, trackpads, etc) to work magically. To fit in as easily as the standard use case (one display, that doesn't hotplug, one focus on one window manager with one keyboard and one tracking device).

Reddit Rants 2: So I wrote a book for a reddit comment

http://www.reddit.com/r/planbshow/comments/1je0xj/regulation_dooms_bitcoin_plan_b_17_bitcoin_podcast/cbe7mv1

So I really like the planb show! I guess I like debating macroeconomics. I can't post the entire conversation here because its a back and forth. 2500 words on the second reply, though!

Software Rants 14: Queue Disciplines

Rabbit hole time! After getting my TR-WDR3600 router to replace a crappy Verizon router/dsl modem combo in preparation for my switch to cablevision internet (for soon ye of 150 KB/s down and 45 KB/s up ye days be numbered) I have dived headfirst into the realm of openwrt, and the myriad of peculiarities that make up IEE 802. 

My most recent confrontation was over outbound queueing - I found my experience using my (constantly bottlenecked) DSL connection pitiful in terms of how well page loads were performing and how responsive websites were under load, so I investigated.

I found a pitiful amount of documentation besides the tc-X man pages on the queue algorithms the kernel supports. I was actually reading the source pages (here are my picks of interest). 

So of course I go right for the shiny new thing, codel. It is a part of the 3.3 kernel buffer bloat tuning. It has to be better than the generic fifo queue, right? The qos package of luci in openwrt always uses hfsc, for example, so it requires elbow grease and an ssh connection to get fq_codel running.

Well, not really. It is just ssh root@router.lan tr qdisc add dev eth0.2 root fq_codel. But it is the thought that counts. 

What did make me happy was the reinforcement of my purchase decision by the Atheros driver (ath71xx) being one of the few kernel 3.3 supported BQL drivers. So that was good. It is currently running on my wan connection, we'll see how it works.

What I found interesting was that apparently the networking in Linux is a real clusterfuck. Who would have known. The bufferbloat problem from a few years ago was, and still is, serious business. And according to documentation 802.11n drivers are much, much worse than just ethernet switches.

It was an educational learning process, though. Codel is a near-stateless, near-bufferless, classless queue discipline that is supposed to handle network variability well and work out of the box, which is exactly what the next generation of network routing algorithms needs. And if it works well, I hope it takes over the world, because fifo queues are so 2002.