Yep. In response the last increase I simply lowered my account tier and started watching Netflix less so that someone else in the family can use the account instead if they feel like it. I expect if Netflix increases the price again I'll drop down to its "single screen" tier or just cancel it completely. Netflix is not *that* valuable to me.
Around 2013 I came the same conclusion and removed GA from all of my websites. It's my opinion that there is no excuse for using cookies for any reason other than a single https-only one for the purpose of keeping people logged in. Server side IP address alone is accurate enough to gauge rough visitor behaviour patterns and the acquisition point (HTTP referrer) is the single only useful metric I personally pay attention to. Ergo, my "analytics" consists of a few lines of C# code which runs against a folder of daily nginx logs, filters out bots/referrer spam and produces a simple table of what's been going on. It's not rocket science.
One nagging question I've always wondered is whether or not google internally demotes websites containing no tracker scripts, on a presumption that "its owner is not working to track visitors/revenue, therefor it is not a serious candidate for these search terms." Even though a product landing page is clean, simple, succinct, and the end product is well received by real users in actually. I'm curious whether or not it's why earlier projects of mine seemed to gather regular organic search traffic and associated business without me even lifting a finger, other than braindead obvious correct usage of search index friendly html markup throughout, contrast to post 2013, when I build a new software product, launch a site for people to find and download it, making sure it looks clean and presentable, mobile friendly, loads quickly, ticks all the best practice boxes - it might as well not even exist. Pretty much the only search term it's considered for is the product name itself through word of mouth.
Hey cool, cheers Mandrel. I like the spirit of DevWheels, thanks for the link. I think the execution might be a bit too wordy, with all the bullet points, caveats and instructions etc. I prefer simple things:)
For developers who build on top of other people's code rather than rolling their own from scratch all of the time, it makes sense that there should be a clear and obvious way for dependency authors to be paid as well. Perhaps a key aspect of a PML could be that licensing only applies to end-user products or server applications. If you're using another author's PML licensed work as part of your own PML library, what you'd do is basically nothing. The other author's code source files remain alongside yours. Downstream products using your library are obliged to pay the other author + you, so they should have two *.pml receipts in their source tree. Simples. Perhaps as a courtesy if components end up with a bunch of PML dependencies, the readme should list them in bullet point form so "consumer" developers don't have to go fishing through every file in the source tree. Or something like GitHub will have already scanned the source tree and have PMLs listed in the clear up front.
Where it all falls apart is when an upstream author drops off the face of the planet and companies can no longer get a license. There's a gap there for GitHub or some company to provide a simple and familiar licensing experience and collect licensing fees in trust. So the purchase link becomes something like: https://github.com/sichbo?pml=.... And there's a tidy little familiar form so you just tick what you need, pay the bill, and receive your *.pml file and get on with life. Maybe throw on a deadman's switch such that *.pmls are issued for $0 when the original author is no longer able to accept payment (destination bank account closed) and a payment transfer issue isn't resolved after 12 months or whatever.
That's a fair point, a non-free license will repel devs willing to spend their time spreading your work. But I guess when an author's objective is to put food on the table 1000 distributions x $0 = $0, so exposure isn't really a factor for them. The only selling point I can think of regarding exposure through OSS is happenstance referrals/support work from some company that has a problem with it which they can't fix themselves or don't want to spend time on. Not exactly sustainable, and it punishes programmers who write their code correctly in the first place:)
That was genuinely interesting, cheers for the link. Having never had any inclination to look up a formal definition I've always just presumed that the spirit of open source licensing was that it remain openly accessible and modifiable and remain as such, not necessarily always free, as in beer. The end-products that rely on them sure as fuck aren't. I suppose what's needed to make things a little more economically sustainable for authors is a new class of "open" licensing that puts dollars in the programmer's pocket whilst still allowing the community at large to benefit from reading, modifying, learning from, security auditing or debugging the publicly visible code. Maybe one could call it Visible Source, VS for short.;)
We have collaboration tools up the wazoo, what's missing is a fair and obvious way to get paid for open source work. I propose a simple OS license to help actually put food on the table for open source developers. Let's call it the "Pay Me License" (PML for short.) It goes quite simply: /*
* PAY ME LICENSE (PML)
*
* Product Name: [Project bundle goes here]
* Copyright (c): [list of owners]
*
* Public Key: [owner's base 64 RSA pub key]
* Purchase Link: mailto|https://whatever?subject=[ProjectName license me]
* Receipt File: [ProjectName].pml
*
* If a the above *.pml receipt file is not in the root of your source
* tree, then this code is not licensed and you are not allowed to use
* it. A license can be obtained from the purchase link above.
*/
That's it. Put it on every source file like any other OSS license. The contents of a *.pml obtained from the source code owner goes something like: /*
* Example *.pml receipt:
*
* From: [Owner(s)] # Must match header
* To: [Your Company you@address.com]
* Product Name: [must match header]
* Receipt: [any text, transaction receipt number]
* Public Key: [base64] # Must match header
* RSA Signature: [base64] # RSA_SIG_OF_UTF8(LOWER_AND_REMOVE_WHITESPACE('From' + 'To' + 'Product Name' + 'Receipt')) */
Any project missing the.pml in its source code tree root, or any.pml file whos signature can't be trivially validated against the public key in the source header is not licensed.
Obviously there's no enforcement, but at the end of the day, even closed source commercial software with complex secret license key validation systems still ultimately depend on people behaving in a civilised manner and not circumventing them. There's also nothing stopping an author from providing license keys to certain worthy causes free of charge.
Same here. So you me and the two ACs make 4. Foolishly I've even just released an app which I use on mine. Just one problem though, and it's now evident that it'll never be fixed -- the WinRT broker infrastructure that's responsible for throttling or allowing apps to run beyond their energy usage quota (on the user's request) is busted, so it's impossible to write a truly reliable connected-standby TCP socket app for Win10 mobile build 15063, the final build we'll probably ever see.
Giving everyone in the world their own HTTP REST endpoint for granting information access to 3rd parties isn't a bad idea on the surface, but I think the implementation here might be a bit too convoluted. I would make an extension to DNS and flow everything based on e-mail address alone, similar to how MX works:
- Your e-mail address is your unique identifier. Just as most sites already use today. - To participate, domains expose a new DNS record of type, let's say "IX" (information exchange) - An IX record on domain.com points to an IX server endpoint... which is nothing more than a REST/WebSocket protocol defined by some spec.
The user's experience for logging in to a 3rd party website becomes:
Email: [ Enter your email ] [ Login ]
User hits Login. The 3rd party does a DNS IX lookup on "domain.com", redirects the user accordingly. By convention: front-part-of-email@domain.com routes to whatever-ix-dns-record.domain.com/front-part-of-email
With GET params ?scope=[attributes]&callback_url=[3rd party url with state information]. Not too dissimilar to OAuth2.
User is now on their personal "IX portal" and can login and grant the 3rd party access to the requested attributes or data stores (predefine/photos,/music,/ical,/mail etc with configurable RWX rights.)
Upon grant, the callback url is hit with access token information and the 3rd party can do whatever with the user's data.
There was an interesting segment regarding shit replacement therapy in a documentary "Life on Us". One of the patients had reported an inexplicable sudden loss of a long term depression after the treatment.
More research in this area would be really great, since a correctly balanced microbiome seems to have positive impacts on a pretty wide range of maladies from obesity to cognitive defects. I've recently been wondering whether or not the only difference between the skinny guy and the fat guy, both eating more or less the same garbage with the same sedentary activity level, is simply gut bacteria/digestive efficiency.
I've implemented UBI in a unified monetary system which attempts to solve most of these issues - https://civil.money/about
The way it attempts to prevent people abusing its UBI is: - Makes all transactions/data publically quantifiable, and uses a number of peers to corroborate all data in a consensus model. - Has a simple credit rating system as well as attributes to infer a person's particular life circumstance "at a glance" for day-to-day essential purchases, however ultimately it is up to each individual on whether or not to accept a person's money. Transaction history can be closely scrutinised/sources traced for higher cost purchases to determine level of legitimacy (its implicit taxation system does this very thing as well behind the scenes.) This is conceptually not much different to what banks do today for any loan. - Turns the concept of money on its head and removes the that artificial sense of scarcity (debt) that we're all so scared of today. - Pegs its value at a constant of time/labour to prevent inflation. - UBI along with inverse-taxation is actually the money creation source.
Features: - A generous universal basic income. Basically the equivalent of USD $60k/yr. - Seeding based on regional productivity (inverse taxation.) Tax is actually a money "creation" process and happens implicitly. - A democratic voting process for any fundamental changes to the system. - A low barrier to entry. Should work just as well for a village in Kenya sharing a single smartphone as anybody standing at a Point-of-Sale terminal. - Transparent transactions and accountability. - Implicit dispute resolution. - A consensus-based scalable distributed P2P architecture. - An efficient and easy to work with messaging format. - End-to-end TLS between all peers and user clients.
Should be releasing it for general "server download" availability and source code on GitHub until around December. Currently held back waiting on critical bug fixes in.NET Core 1.1 to be released.
Lately I've been working on a monetary system. Bit different to fiat or blockchain currencies. It's using a p2p distributed hash table for data storage, encryption happens strictly "on the client" for RSA signing procedures, it includes a basic cost of living, implicit taxation, and it has more of a focus on "good standing" rather than debt. It's probably not exactly ready for prime time, but I'd be interested in yours, or anybody else's thoughts: http://pretend.money/preview
My account for example is http://pretend.money/preview/#...
Mostly I just wanted to see what a monetary system that is not based on "debt" might look like. Bit of fun.
Whatever happened to that rockin' skateboard concept which had a swappable body. The Volt has been a bit of a disappointment in terms of design aesthetics and forward thinking, compared to GM's early electric/hydrogen concept. Do you think the skateboard idea will ever see the light of day, perhaps as a Ni-Cd battery car?
Just wanted to say thanks for the Studio One suggestion. Having been out of the music recording loop since 2000 this/. question piqued my interest around what's available these days.. and that particular suggestion looks like a good fit for getting back into composing/recording on Windows.
If it's anything like the Samsung Slate 7 (similar to the device given out during the 2011 BUILD conference for win8 developer launch) I reckon the Pro should do OK. I paid $1400 for a slate 7 about a year ago and loaded on the various preview win8 builds.. to this day it's still working good as a complete laptop/desktop replacement. You basically have an 128GB i5 "ultrabook" spec machine, but with a separate bluetooth keyboard (mine eventually broke so replaced with a proper $15 USB keyboard.) When docked you have a very small footprint workstation with HDMI out for large monitor, LAN port, audio out, 2x USB ports (one on the dock, one on the tablet, although I just use a hub out of the dock for mouse+keys and leave the side USB port for TV tuners etc.) At the end of the work day, pick it up off the dock and walk around with it and consume content. Runs for a good 4-5 hrs on battery if doing "nothing intensive" or enough to watch two feature films. I suspect the "pro" will give more or less the same viability as a "laptop/desktop replacement".
To be fair, it depends a lot on the speakers... listening through the usual consumer playback devices (headphones, docks, PC speakers, home theatre systems) probably not because they can't reproduce all of the frequencies without adding colour or omitting some entirely anyway. Listen to the mp3 through a set of professional monitors or quality stereo towers of moderate quality (Polk Audio, et al) and you'll find the mp3 does in fact sound pretty bad. When I started sourcing more uncompressed music and playing it through better gear, I found myself re-discovering a lot of old songs from the past 15 years. Everything is brighter, sharper, more dynamic, less muddy/boomy than the 128/160/192 mp3 files of the same songs I have kicking around.
In Canada, it's illegal to practice engineering, or call yourself one, without a engineers license. There's nothing worse than retards who get a college degree in programming and start calling themselves "engineers". It's an insult to every actual certified engineer in the world.
Without actually checking on the API yet, I wonder how Google plan on thwarting people from writing rubbish code which could potentially overtake your preferred IntentReceivers (ie "Go Home") which in turn mimics an original app but starts doing naughty things in the background like trying to infect contacts in your addressbook.
With the completely outlandish tariffs on GPRS data, simple bandwidth consuming viruses on any cell phone would seriously hurt someone financially. I really hope Google have solid code execution prevention..
Slashdot Mirror
Yep. In response the last increase I simply lowered my account tier and started watching Netflix less so that someone else in the family can use the account instead if they feel like it. I expect if Netflix increases the price again I'll drop down to its "single screen" tier or just cancel it completely. Netflix is not *that* valuable to me.
This was the best thing I read all day.
Around 2013 I came the same conclusion and removed GA from all of my websites. It's my opinion that there is no excuse for using cookies for any reason other than a single https-only one for the purpose of keeping people logged in. Server side IP address alone is accurate enough to gauge rough visitor behaviour patterns and the acquisition point (HTTP referrer) is the single only useful metric I personally pay attention to. Ergo, my "analytics" consists of a few lines of C# code which runs against a folder of daily nginx logs, filters out bots/referrer spam and produces a simple table of what's been going on. It's not rocket science.
One nagging question I've always wondered is whether or not google internally demotes websites containing no tracker scripts, on a presumption that "its owner is not working to track visitors/revenue, therefor it is not a serious candidate for these search terms." Even though a product landing page is clean, simple, succinct, and the end product is well received by real users in actually. I'm curious whether or not it's why earlier projects of mine seemed to gather regular organic search traffic and associated business without me even lifting a finger, other than braindead obvious correct usage of search index friendly html markup throughout, contrast to post 2013, when I build a new software product, launch a site for people to find and download it, making sure it looks clean and presentable, mobile friendly, loads quickly, ticks all the best practice boxes - it might as well not even exist. Pretty much the only search term it's considered for is the product name itself through word of mouth.
Hey cool, cheers Mandrel. I like the spirit of DevWheels, thanks for the link. I think the execution might be a bit too wordy, with all the bullet points, caveats and instructions etc. I prefer simple things :)
For developers who build on top of other people's code rather than rolling their own from scratch all of the time, it makes sense that there should be a clear and obvious way for dependency authors to be paid as well. Perhaps a key aspect of a PML could be that licensing only applies to end-user products or server applications. If you're using another author's PML licensed work as part of your own PML library, what you'd do is basically nothing. The other author's code source files remain alongside yours. Downstream products using your library are obliged to pay the other author + you, so they should have two *.pml receipts in their source tree. Simples. Perhaps as a courtesy if components end up with a bunch of PML dependencies, the readme should list them in bullet point form so "consumer" developers don't have to go fishing through every file in the source tree. Or something like GitHub will have already scanned the source tree and have PMLs listed in the clear up front.
Where it all falls apart is when an upstream author drops off the face of the planet and companies can no longer get a license. There's a gap there for GitHub or some company to provide a simple and familiar licensing experience and collect licensing fees in trust. So the purchase link becomes something like: https://github.com/sichbo?pml=.... And there's a tidy little familiar form so you just tick what you need, pay the bill, and receive your *.pml file and get on with life. Maybe throw on a deadman's switch such that *.pmls are issued for $0 when the original author is no longer able to accept payment (destination bank account closed) and a payment transfer issue isn't resolved after 12 months or whatever.
That's a fair point, a non-free license will repel devs willing to spend their time spreading your work. But I guess when an author's objective is to put food on the table 1000 distributions x $0 = $0, so exposure isn't really a factor for them. The only selling point I can think of regarding exposure through OSS is happenstance referrals/support work from some company that has a problem with it which they can't fix themselves or don't want to spend time on. Not exactly sustainable, and it punishes programmers who write their code correctly in the first place :)
That was genuinely interesting, cheers for the link. Having never had any inclination to look up a formal definition I've always just presumed that the spirit of open source licensing was that it remain openly accessible and modifiable and remain as such, not necessarily always free, as in beer. The end-products that rely on them sure as fuck aren't. I suppose what's needed to make things a little more economically sustainable for authors is a new class of "open" licensing that puts dollars in the programmer's pocket whilst still allowing the community at large to benefit from reading, modifying, learning from, security auditing or debugging the publicly visible code. Maybe one could call it Visible Source, VS for short. ;)
We have collaboration tools up the wazoo, what's missing is a fair and obvious way to get paid for open source work. I propose a simple OS license to help actually put food on the table for open source developers. Let's call it the "Pay Me License" (PML for short.) It goes quite simply:
/*
* PAY ME LICENSE (PML)
*
* Product Name: [Project bundle goes here]
* Copyright (c): [list of owners]
*
* Public Key: [owner's base 64 RSA pub key]
* Purchase Link: mailto|https://whatever?subject=[ProjectName license me]
* Receipt File: [ProjectName].pml
*
* If a the above *.pml receipt file is not in the root of your source
* tree, then this code is not licensed and you are not allowed to use
* it. A license can be obtained from the purchase link above.
*/
That's it. Put it on every source file like any other OSS license. The contents of a *.pml obtained from the source code owner goes something like:
/*
* Example *.pml receipt:
*
* From: [Owner(s)] # Must match header
* To: [Your Company you@address.com]
* Product Name: [must match header]
* Receipt: [any text, transaction receipt number]
* Public Key: [base64] # Must match header
* RSA Signature: [base64] # RSA_SIG_OF_UTF8(LOWER_AND_REMOVE_WHITESPACE('From' + 'To' + 'Product Name' + 'Receipt'))
*/
Any project missing the .pml in its source code tree root, or any .pml file whos signature can't be trivially validated against the public key in the source header is not licensed.
Obviously there's no enforcement, but at the end of the day, even closed source commercial software with complex secret license key validation systems still ultimately depend on people behaving in a civilised manner and not circumventing them. There's also nothing stopping an author from providing license keys to certain worthy causes free of charge.
Same here. So you me and the two ACs make 4. Foolishly I've even just released an app which I use on mine. Just one problem though, and it's now evident that it'll never be fixed -- the WinRT broker infrastructure that's responsible for throttling or allowing apps to run beyond their energy usage quota (on the user's request) is busted, so it's impossible to write a truly reliable connected-standby TCP socket app for Win10 mobile build 15063, the final build we'll probably ever see.
Economics reboot? "Here's one I've prepared earlier!" - https://civil.money/about
Hilarious :) no doubt named after the kiwi song - https://flightoftheconchords.b...
Giving everyone in the world their own HTTP REST endpoint for granting information access to 3rd parties isn't a bad idea on the surface, but I think the implementation here might be a bit too convoluted. I would make an extension to DNS and flow everything based on e-mail address alone, similar to how MX works:
- Your e-mail address is your unique identifier. Just as most sites already use today.
- To participate, domains expose a new DNS record of type, let's say "IX" (information exchange)
- An IX record on domain.com points to an IX server endpoint... which is nothing more than a REST/WebSocket protocol defined by some spec.
The user's experience for logging in to a 3rd party website becomes:
Email: [ Enter your email ]
[ Login ]
User hits Login. The 3rd party does a DNS IX lookup on "domain.com", redirects the user accordingly. By convention:
front-part-of-email@domain.com routes to whatever-ix-dns-record.domain.com/front-part-of-email
With GET params ?scope=[attributes]&callback_url=[3rd party url with state information]. Not too dissimilar to OAuth2.
User is now on their personal "IX portal" and can login and grant the 3rd party access to /photos, /music, /ical, /mail etc with configurable RWX rights.)
the requested attributes or data stores (predefine
Upon grant, the callback url is hit with access token information and the 3rd party can do whatever with the user's data.
There was an interesting segment regarding shit replacement therapy in a documentary "Life on Us". One of the patients had reported an inexplicable sudden loss of a long term depression after the treatment.
More research in this area would be really great, since a correctly balanced microbiome seems to have positive impacts on a pretty wide range of maladies from obesity to cognitive defects. I've recently been wondering whether or not the only difference between the skinny guy and the fat guy, both eating more or less the same garbage with the same sedentary activity level, is simply gut bacteria/digestive efficiency.
I've implemented UBI in a unified monetary system which attempts to solve most of these issues - https://civil.money/about
The way it attempts to prevent people abusing its UBI is:
- Makes all transactions/data publically quantifiable, and uses a number of peers to corroborate all data in a consensus model.
- Has a simple credit rating system as well as attributes to infer a person's particular life circumstance "at a glance" for day-to-day essential purchases, however ultimately it is up to each individual on whether or not to accept a person's money. Transaction history can be closely scrutinised/sources traced for higher cost purchases to determine level of legitimacy (its implicit taxation system does this very thing as well behind the scenes.) This is conceptually not much different to what banks do today for any loan.
- Turns the concept of money on its head and removes the that artificial sense of scarcity (debt) that we're all so scared of today.
- Pegs its value at a constant of time/labour to prevent inflation.
- UBI along with inverse-taxation is actually the money creation source.
Figure the main problem in the world today is its monetary system, so have built this:
https://civil.money/about
The trick will be convincing anybody to use it.
Features:
- A generous universal basic income. Basically the equivalent of USD $60k/yr.
- Seeding based on regional productivity (inverse taxation.) Tax is actually a money "creation" process and happens implicitly.
- A democratic voting process for any fundamental changes to the system.
- A low barrier to entry. Should work just as well for a village in Kenya sharing a single smartphone as anybody standing at a Point-of-Sale terminal.
- Transparent transactions and accountability.
- Implicit dispute resolution.
- A consensus-based scalable distributed P2P architecture.
- An efficient and easy to work with messaging format.
- End-to-end TLS between all peers and user clients.
Draft technical bits here: https://civil.money/api
Should be releasing it for general "server download" availability and source code on GitHub until around December. Currently held back waiting on critical bug fixes in .NET Core 1.1 to be released.
Lately I've been working on a monetary system. Bit different to fiat or blockchain currencies. It's using a p2p distributed hash table for data storage, encryption happens strictly "on the client" for RSA signing procedures, it includes a basic cost of living, implicit taxation, and it has more of a focus on "good standing" rather than debt. It's probably not exactly ready for prime time, but I'd be interested in yours, or anybody else's thoughts: http://pretend.money/preview My account for example is http://pretend.money/preview/#... Mostly I just wanted to see what a monetary system that is not based on "debt" might look like. Bit of fun.
Whatever happened to that rockin' skateboard concept which had a swappable body. The Volt has been a bit of a disappointment in terms of design aesthetics and forward thinking, compared to GM's early electric/hydrogen concept. Do you think the skateboard idea will ever see the light of day, perhaps as a Ni-Cd battery car?
Just wanted to say thanks for the Studio One suggestion. Having been out of the music recording loop since 2000 this /. question piqued my interest around what's available these days.. and that particular suggestion looks like a good fit for getting back into composing/recording on Windows.
If it's anything like the Samsung Slate 7 (similar to the device given out during the 2011 BUILD conference for win8 developer launch) I reckon the Pro should do OK. I paid $1400 for a slate 7 about a year ago and loaded on the various preview win8 builds.. to this day it's still working good as a complete laptop/desktop replacement. You basically have an 128GB i5 "ultrabook" spec machine, but with a separate bluetooth keyboard (mine eventually broke so replaced with a proper $15 USB keyboard.) When docked you have a very small footprint workstation with HDMI out for large monitor, LAN port, audio out, 2x USB ports (one on the dock, one on the tablet, although I just use a hub out of the dock for mouse+keys and leave the side USB port for TV tuners etc.) At the end of the work day, pick it up off the dock and walk around with it and consume content. Runs for a good 4-5 hrs on battery if doing "nothing intensive" or enough to watch two feature films. I suspect the "pro" will give more or less the same viability as a "laptop/desktop replacement".
To be fair, it depends a lot on the speakers... listening through the usual consumer playback devices (headphones, docks, PC speakers, home theatre systems) probably not because they can't reproduce all of the frequencies without adding colour or omitting some entirely anyway. Listen to the mp3 through a set of professional monitors or quality stereo towers of moderate quality (Polk Audio, et al) and you'll find the mp3 does in fact sound pretty bad. When I started sourcing more uncompressed music and playing it through better gear, I found myself re-discovering a lot of old songs from the past 15 years. Everything is brighter, sharper, more dynamic, less muddy/boomy than the 128/160/192 mp3 files of the same songs I have kicking around.
In Canada, it's illegal to practice engineering, or call yourself one, without a engineers license. There's nothing worse than retards who get a college degree in programming and start calling themselves "engineers". It's an insult to every actual certified engineer in the world.
Without actually checking on the API yet, I wonder how Google plan on thwarting people from writing rubbish code which could potentially overtake your preferred IntentReceivers (ie "Go Home") which in turn mimics an original app but starts doing naughty things in the background like trying to infect contacts in your addressbook.
With the completely outlandish tariffs on GPRS data, simple bandwidth consuming viruses on any cell phone would seriously hurt someone financially. I really hope Google have solid code execution prevention ..