My jaw dropped in amazement. The fact the technique is extensible to other sensory and brain malfunctions seems to be just icing on the cake.
Eureka, now we can actually create penis enlargement technology! It would be fully customizable and detachable! A baker could even have theirs eject delicious icing all over your cake!
These are things that are more valuable than most "geeks" will ever admit to the willingness of people to buy, use, and feel good about certain products, and are therefore incredibly valuable when they're done right and worth spending a lot of money to develop a great solution.
No. Those things are gimmicks that ONLY "geeks" notice, the general populous caring much more about what the device can ACTUALLY do whether than precisely how it does it. If you can stumble upon a patent, then it's fucking obvious. To say otherwise is to sit in your conceptually constructed tower and pontificate profusely over minutia that wrongfully drains BILLIONS of dollars from the world's economies below, only for the benefit of your own sick disconnected ilk.
Take note: The Intangible Machine Invasion is upon us. The above poster is "one of them", and should be put down. Re-watch the Terminator series and the 1st (and only) Matrix movie -- The legal frameworks are the machines that rule mankind.
If your bullshit design nuances are so damn important and valuable then how do you explain the success of Fashion Industry or Automotive Industry? --Neither of which have said design patent protections, and yet remain valuable and lucrative. How much do the intellectual property taxes cost us all? I put it to you that such patents necessarily cost us MUCH more than were they eradicated; They necessarily create jobs for intangible instruction code processing units -- Lawyers -- that also otherwise would not need to exist.
You think you're a human?! NO. YOU'RE PART OF THE MACHINE!
I always thought these were fairly constant, does this theory mess up any of our current Radiometric dating (and other similar) methods?
Well, No: Considering the predictability is consistently of random accuracy in any form of dating, be it Radiometric, Electronic, Speed, Blind, or chance reliant encounters. They might have a statistically significant effect on dating if the solar flares dramatically affect hormone or pheromone production.
In my experience the Moon is a much better indicator of whether dating will be "successful"...
I completely agree. BASIC was my first language. C was my second, and before I could fully learn it I delved into Assembly.
It wasn't until Assembly that I met the man behind the curtain, we shook hands and he imparted his "wizardry" to me. I went back and mastered C in a week. All other languages became simply syntax rules and a new API -- A few weeks work to get proficient in the language and then just having API docs available. I can more quickly understand the high level languages like Haskel, C++, Java, etc. now that I know what the hell is actually going on.
I tried teaching my little brother JS, it didn't work out... So we tried C, he couldn't get "pointers" and their associated arithmetic. We tried Assembly and he took off! In my experience, the magic of higher level languages is only empowering if you grasp the sufficiently advanced technology on which the magic is based.
Additionally, since I can run an assembly program on a sheet of graph paper it's been astounding to see software patents being granted...
Yes, it does have some dangerous gotchas, so the trick is to avoid those areas of the language
No "the trick" is to get people to overlook the bullshit rather than use a better language or actually fucking fix it... If you have to avoid an area of the language then the language is BROKEN.
Yep, and it's there for the same reason as other entrenched bullshit is still around -- Not because it's any good at all, just because it's what we have available to work with. As someone who uses JavaScript as well as nearly all other "popular" languages, from C++ to Perl, to PHP, Assembly, I must say, JS is my least favorite to work with -- Let me just repeat that: I MAINTAIN PHP CODE, AND THINK JS IS WORSE!
It's a crappy language, with designs that needlessly screw performance, that was never intended to be used the way we NEED it to be used today. We'd be better off with ANY other scripting language. Hell, I'd rather use Lua in a browser than JavaScript. The only reason we use it is because nothing else has as broad support, not really on any merit of the language itself.
And then there's folks like me, who need to render out video from their games, and would like to enable end users to click a button and have the replay of game footage uploaded to youtube (or placed in a folder) -- because I need to make the video w/o screen recorders myself anyway. I have a plugin system for handling the video encoding so I can create multiple encoders, but the only encoder I can actually AFFORD to ship is WebM (or Theora, but I only have so much time)... I'm using Google's code at current in my WebM plugin implementation, but I've seen many cases where I could create GPU shaders to do WebM encoding or decoding more efficiently than they do... My software is a Game, so I can rely on the minimum GPU specs being higher than WebM can afford at present. I don't see any reason that WebM couldn't detect the shader support and use hardware decoding over CPU decoding if available.
As mobiles get more powerful shader support, and heterogeneous computing becomes more pervasive, I don't see any reason to choose H.264 over WebM -- The patent and licensing BS of H.264 are enough to swing my vote to WebM. "Hardware Decoding" out of the box doesn't mean a whole hell of a lot if either decoder is running on the GPU... It's really all about adoption. Google didn't get GPU MFGs on board for their implementation for whatever reason, so we have H.264 "in hardware"
o_O (I suspect this means it's in that binary blob that gets uploaded to the GPU, so "in firmware" would be a better name for it).
I wonder what sort of license Mozilla has? I mean, Will I still be able to compile my own Firefox and get H.264 support via their licensing deal? Actually this isn't "Mozilla" it's just some dude who works for Mozilla. It would be like a Ford factor line worker adding hydros to her personal Mustang, then someone headilnes: Ford is experimenting with crazy-ass Hydrolic lift kits on new Mustangs!
Yep, it'll keep compiling C properly. The real issue here is compiling C++, not C. You see, C++ uses many of the C language implementation. Eg: Function names are munged into unique C function names prior to compiling...
The C++ language is running into walls where C implementation details are difficult to work around. Moving the C compiler codebase to C++ allows C++ compiler to more easily advance. C itself will be largely unaffected, it just makes developing C++ easier.
I've gone the opposite direction. Moving more of my C++ code into C by using my own OOP system. Before you say "That's crazy talk", consider that it makes inter-operating with my game's scripting language so much more buttery smooth than in C++ -- It's so nice to just create a new object in either script or C and have them talk to each other without going through a few layers of APIs, passing off dynamically allocated instances and having C free it, or the script GC it automatically.
Don't get me wrong, I love C++, but they have rules that are conflicting when you get "deep" into the language. Try using multiple inheritance and polymorphism... It almost works, but not if you have two base classes with the same virtual function names -- That's just one of many edge cases I ran into... Theres several corners we're forbidden to go where templates, type safety, and inheritance don't play well with each other...
After a while I just scratched my head, "Really C++? Really?!" Why would you have features that are incompatible? So long as I only use some of C++'s features some of the time, then everything is fine, but when I needed to use MOST of the language in the implementation of my scripting language, then shit hit the fan. Many experience people I look up to have told me if I need to use the WHOLE C++ language then I'm doing it wrong. To them I say: If you can't use the entire language at once then the Language is "doing it wrong".
C++ is great if you're only using C++, and C++ constructs. That you have to use extern "C" {... } to make shared libs that will actually work with other compilers or languages is a serious show-stopper for me. Protip: method names are munged into unique C function names so you can actually compile "C++", ergo they need to standardize name munging rules but to do that would be to admit that C++ is mostly implemented as a fancy pre-processor for C...
Most of my C++ code was contained in extern "C" blocks, and I had abandoned most of the C++ features for my own language's simpler implementations, so one day I woke up and realized I should stop fighting C++ and just use C.
My problem was that I needed a language that let me closely express the construct of another language within it -- embedability was a prime factor. Sure I could write the VM in C++, and have a ton of interfaces and abstraction and overloaded operators, etc, but with C I didn't need to do that.
Some of the reasons I left C++ for are being fixed / added in C++2012, but it's too late for me. I'm not going back. I'll use C++ for my C++ only projects, but for anything that needs to work with other languages (most of my code), then I'll use C. Bonus: Instead of 15 minutes to compile the C++ implementation, it takes just seconds as C.
C has many pitfalls, but at least they're out in plain sight; Unlike the C++ pitfalls, which are hidden in corners, shrouded in "advanced feature" mystery, and blanketed by the fog of denialism -- When things that should work according to spec don't (because of the implementation details), then you do you really have a language, or is it just part of a language?
C++ has the same problem with C that I experienced with C++ -- When you try to implement a language in a way that's really close to another language, so you can use its underlying tool-chain, you run into a point where you must be shackled by the base language's implementation details... You can either build around the limitations (what C++ does), or you can embrace them (what I've done). Unfortunately I couldn't embrace the C++ implementation -- a complete one doesn't exist.
You write a damn exception handler block every time you have a "new". If you're using Linux and you run out of VRAM, it just starts killing processes until it has the memory. Its "optimistic" allocator doesn't throw std::bad_alloc -- is some really scary shit.
I assure you your refrigerator temperature thermostat was not programmed in GCC.
That's because its CPU is a bi-metallic strip wound into a coil, and it's RAM is only one bit. The equivalent of running.configure and make is rotating a dial and tightening a screw.
Once it knows it has the correct configuration, it rehashes that pair with a different salt to get an RC4 encryption key which unlocks the payload.
I'm old, lazy and patient. This is where I would start, not by finding the correct combinations of inputs, but brute forcing the MD5, or trying to pull out bits of the symmetric stream cipher via known plaintext attack -- It's encrypted machine code, it's going to have machine code in the payload.
If I actually gave a damn I'd set up the algorithm to generate their flavor of salted MD5, then start a Kickstarter to get it on Amazon's compute, and also distribute CPU and GPU versions and job/batch assignments to help crack it via distributed computing. Maybe save a section of the donated funds to reward the discoverer.
Due to the entropy loss in MD5, the algorithm itself adds characteristics to the output data. Some of these characteristics are compounded in iterative key stretching. Thus it's actually faster to do the key stretching to find the key than building a rainbow table for the last iteration -- the stretching itself helps build the characteristics that lead to hash collisions. If they wanted to slow us down, the morons should have used SHA-512 -- all the hash algorithms are trivial to implement (I've done them all in every language from Assembly to JavaScript in less than a week of evenings).
If you really wanted to deliver some secret code, that targets specific systems, and have it be very tiny to the point of being nearly unnoticeable, then I'd also use return oriented programming.
The spooks ain't spooky enough to be real hackers, IMO.
When you go to a web site that "stores cookies" in your browser, what happens is that a HTTP "Set-Cookie" header is sent to your browser. YOU HAVE THE POWER TO DISABLE COOKIES in your browser. It's not like the remote site can make your browser save the cookie.
The user already has every capability to prevent the remote sites from storing any cookies. Simply DISABLE ALL COOKIES. Then, if you run across a site that has a feature requiring cookies (stateful sessions, like logging in), then and ONLY THEN DO YOU ENABLE COOKIES for that site alone. White list it. Oh your browser doesn't have a white list? YES IT DOES. IE does. FF has the Cookie Monster plugin among other ways, Chrome has -- Fuck Chrome! Chromium Exists. Chrome is closed source and has Google's secret advertising sauce added if you don't like cookies why would you use Chrome?! Google Sells Ads.
Now, being a primordial deep one from time immemorial, I remember an age before cookies existed. I used caller ID, bitrate and handshake timings to log and verify my visitors' identity in the BBS era. Then came the Internet. I used a hash of the user agent, IP address, and other header strings along with URL munging (crazy crap you see after the ? in your address bar) to identify and verify users. Cookies allowed us to stop crapping up every URL on the page, and causing massive link rot... So, you want to make laws about cookies, eh? Well there are levels of tracking we are willing to accept, and we don't even need the damn cookies to do so. Enjoy server side storage of your IP address, browser signatures, and Query Strings cocking up your bullshit European URLs....
Get bent morons. Cookies are good for you, at least YOU can control them. You can't very well control whether or not servers use URL munging....
Oh, its actually an article? Well then, it should read: What Happens When Google Employees Die?
Considering it's supposed to be an article instead of a thinly veiled slashvertizement, I still say it's all hogwash; Totally just hypothetical conjecture. No one really knows what will actually happen until we test the hypothesis. Murder?! NO, Science!
Can you please get the webmasters to hash our passwords instead of storing them in the DB in cleartext, and limiting the number and type of characters I can provide? If you work at a bank that already does this, may the gods favor you; Otherwise... Well, at least you have this contingency plan.
We don't have a good term for what Apple does. As you point out, it isn't QUITE trolling since they are producing products. However, they certainly do seem to be employing the same sleezy tactics.
Those sleazy tactics involve weaving a collection of questionable or down right bogus patents into a lawsuit, then casting it any and all opponents in the hopes to hamper them or catch a few who are unable to litigate, thus netting huge settlements. Sounds pretty much like the definition of trolling to me -- Drag-Net is another name for trolling too. Have you ever even been fishing before? Or has the Internet leached away all other reality leaving only it's pedantically demented definition of "troll" in tact and removing any connection to its basis in the aforementioned fishing acts?
I'm a former iPhone user, currently on Android. It's more customizable, all right... but "better"? I would not say that is true for the "normal" user. I'll probably get a Windows phone next
, just to screw around with that... But it has taken me a few months to get it to where I don't feel the need, for example, to download a couple dozen keyboards
until I find one that works as well as the iPhone's.
Slashdot Mirror
My jaw dropped in amazement. The fact the technique is extensible to other sensory and brain malfunctions seems to be just icing on the cake.
Eureka, now we can actually create penis enlargement technology! It would be fully customizable and detachable! A baker could even have theirs eject delicious icing all over your cake!
These are things that are more valuable than most "geeks" will ever admit to the willingness of people to buy, use, and feel good about certain products, and are therefore incredibly valuable when they're done right and worth spending a lot of money to develop a great solution.
No. Those things are gimmicks that ONLY "geeks" notice, the general populous caring much more about what the device can ACTUALLY do whether than precisely how it does it. If you can stumble upon a patent, then it's fucking obvious. To say otherwise is to sit in your conceptually constructed tower and pontificate profusely over minutia that wrongfully drains BILLIONS of dollars from the world's economies below, only for the benefit of your own sick disconnected ilk.
Take note: The Intangible Machine Invasion is upon us. The above poster is "one of them", and should be put down. Re-watch the Terminator series and the 1st (and only) Matrix movie -- The legal frameworks are the machines that rule mankind.
If your bullshit design nuances are so damn important and valuable then how do you explain the success of Fashion Industry or Automotive Industry? --Neither of which have said design patent protections, and yet remain valuable and lucrative. How much do the intellectual property taxes cost us all? I put it to you that such patents necessarily cost us MUCH more than were they eradicated; They necessarily create jobs for intangible instruction code processing units -- Lawyers -- that also otherwise would not need to exist.
You think you're a human?! NO. YOU'RE PART OF THE MACHINE!
I always thought these were fairly constant, does this theory mess up any of our current Radiometric dating (and other similar) methods?
Well, No: Considering the predictability is consistently of random accuracy in any form of dating, be it Radiometric, Electronic, Speed, Blind, or chance reliant encounters. They might have a statistically significant effect on dating if the solar flares dramatically affect hormone or pheromone production.
In my experience the Moon is a much better indicator of whether dating will be "successful"...
I completely agree. BASIC was my first language. C was my second, and before I could fully learn it I delved into Assembly.
It wasn't until Assembly that I met the man behind the curtain, we shook hands and he imparted his "wizardry" to me. I went back and mastered C in a week. All other languages became simply syntax rules and a new API -- A few weeks work to get proficient in the language and then just having API docs available. I can more quickly understand the high level languages like Haskel, C++, Java, etc. now that I know what the hell is actually going on.
I tried teaching my little brother JS, it didn't work out... So we tried C, he couldn't get "pointers" and their associated arithmetic. We tried Assembly and he took off! In my experience, the magic of higher level languages is only empowering if you grasp the sufficiently advanced technology on which the magic is based.
Additionally, since I can run an assembly program on a sheet of graph paper it's been astounding to see software patents being granted...
Yes, it does have some dangerous gotchas, so the trick is to avoid those areas of the language
No "the trick" is to get people to overlook the bullshit rather than use a better language or actually fucking fix it... If you have to avoid an area of the language then the language is BROKEN.
Yep, and it's there for the same reason as other entrenched bullshit is still around -- Not because it's any good at all, just because it's what we have available to work with. As someone who uses JavaScript as well as nearly all other "popular" languages, from C++ to Perl, to PHP, Assembly, I must say, JS is my least favorite to work with -- Let me just repeat that: I MAINTAIN PHP CODE, AND THINK JS IS WORSE!
It's a crappy language, with designs that needlessly screw performance, that was never intended to be used the way we NEED it to be used today. We'd be better off with ANY other scripting language. Hell, I'd rather use Lua in a browser than JavaScript. The only reason we use it is because nothing else has as broad support, not really on any merit of the language itself.
JavaScript is the Microsoft of "Web" Languages.
And my brand new social network Rossy, not yet released, containing at present exactly one post which is not junk, has a S/N ratio of infinity.
So much for S/N as a metric.
No it does not. Signal to Noise of 1 / 0 is a division by zero error, not infinity.
And then there's folks like me, who need to render out video from their games, and would like to enable end users to click a button and have the replay of game footage uploaded to youtube (or placed in a folder) -- because I need to make the video w/o screen recorders myself anyway. I have a plugin system for handling the video encoding so I can create multiple encoders, but the only encoder I can actually AFFORD to ship is WebM (or Theora, but I only have so much time)... I'm using Google's code at current in my WebM plugin implementation, but I've seen many cases where I could create GPU shaders to do WebM encoding or decoding more efficiently than they do... My software is a Game, so I can rely on the minimum GPU specs being higher than WebM can afford at present. I don't see any reason that WebM couldn't detect the shader support and use hardware decoding over CPU decoding if available.
As mobiles get more powerful shader support, and heterogeneous computing becomes more pervasive, I don't see any reason to choose H.264 over WebM -- The patent and licensing BS of H.264 are enough to swing my vote to WebM. "Hardware Decoding" out of the box doesn't mean a whole hell of a lot if either decoder is running on the GPU... It's really all about adoption. Google didn't get GPU MFGs on board for their implementation for whatever reason, so we have H.264 "in hardware"
o_O (I suspect this means it's in that binary blob that gets uploaded to the GPU, so "in firmware" would be a better name for it).
I wonder what sort of license Mozilla has? I mean, Will I still be able to compile my own Firefox and get H.264 support via their licensing deal? Actually this isn't "Mozilla" it's just some dude who works for Mozilla. It would be like a Ford factor line worker adding hydros to her personal Mustang, then someone headilnes: Ford is experimenting with crazy-ass Hydrolic lift kits on new Mustangs!
Yep, it'll keep compiling C properly. The real issue here is compiling C++, not C. You see, C++ uses many of the C language implementation. Eg: Function names are munged into unique C function names prior to compiling...
The C++ language is running into walls where C implementation details are difficult to work around. Moving the C compiler codebase to C++ allows C++ compiler to more easily advance. C itself will be largely unaffected, it just makes developing C++ easier.
I've gone the opposite direction. Moving more of my C++ code into C by using my own OOP system. Before you say "That's crazy talk", consider that it makes inter-operating with my game's scripting language so much more buttery smooth than in C++ -- It's so nice to just create a new object in either script or C and have them talk to each other without going through a few layers of APIs, passing off dynamically allocated instances and having C free it, or the script GC it automatically.
Don't get me wrong, I love C++, but they have rules that are conflicting when you get "deep" into the language. Try using multiple inheritance and polymorphism... It almost works, but not if you have two base classes with the same virtual function names -- That's just one of many edge cases I ran into... Theres several corners we're forbidden to go where templates, type safety, and inheritance don't play well with each other...
After a while I just scratched my head, "Really C++? Really?!" Why would you have features that are incompatible? So long as I only use some of C++'s features some of the time, then everything is fine, but when I needed to use MOST of the language in the implementation of my scripting language, then shit hit the fan. Many experience people I look up to have told me if I need to use the WHOLE C++ language then I'm doing it wrong. To them I say: If you can't use the entire language at once then the Language is "doing it wrong".
C++ is great if you're only using C++, and C++ constructs. That you have to use extern "C" { ... } to make shared libs that will actually work with other compilers or languages is a serious show-stopper for me. Protip: method names are munged into unique C function names so you can actually compile "C++", ergo they need to standardize name munging rules but to do that would be to admit that C++ is mostly implemented as a fancy pre-processor for C...
Most of my C++ code was contained in extern "C" blocks, and I had abandoned most of the C++ features for my own language's simpler implementations, so one day I woke up and realized I should stop fighting C++ and just use C.
My problem was that I needed a language that let me closely express the construct of another language within it -- embedability was a prime factor. Sure I could write the VM in C++, and have a ton of interfaces and abstraction and overloaded operators, etc, but with C I didn't need to do that.
Some of the reasons I left C++ for are being fixed / added in C++2012, but it's too late for me. I'm not going back. I'll use C++ for my C++ only projects, but for anything that needs to work with other languages (most of my code), then I'll use C. Bonus: Instead of 15 minutes to compile the C++ implementation, it takes just seconds as C.
C has many pitfalls, but at least they're out in plain sight; Unlike the C++ pitfalls, which are hidden in corners, shrouded in "advanced feature" mystery, and blanketed by the fog of denialism -- When things that should work according to spec don't (because of the implementation details), then you do you really have a language, or is it just part of a language?
C++ has the same problem with C that I experienced with C++ -- When you try to implement a language in a way that's really close to another language, so you can use its underlying tool-chain, you run into a point where you must be shackled by the base language's implementation details... You can either build around the limitations (what C++ does), or you can embrace them (what I've done). Unfortunately I couldn't embrace the C++ implementation -- a complete one doesn't exist.
You write a damn exception handler block every time you have a "new". If you're using Linux and you run out of VRAM, it just starts killing processes until it has the memory. Its "optimistic" allocator doesn't throw std::bad_alloc -- is some really scary shit.
I assure you your refrigerator temperature thermostat was not programmed in GCC.
That's because its CPU is a bi-metallic strip wound into a coil, and it's RAM is only one bit. The equivalent of running .configure and make is rotating a dial and tightening a screw.
Once it knows it has the correct configuration, it rehashes that pair with a different salt to get an RC4 encryption key which unlocks the payload.
I'm old, lazy and patient. This is where I would start, not by finding the correct combinations of inputs, but brute forcing the MD5, or trying to pull out bits of the symmetric stream cipher via known plaintext attack -- It's encrypted machine code, it's going to have machine code in the payload.
If I actually gave a damn I'd set up the algorithm to generate their flavor of salted MD5, then start a Kickstarter to get it on Amazon's compute, and also distribute CPU and GPU versions and job/batch assignments to help crack it via distributed computing. Maybe save a section of the donated funds to reward the discoverer.
Due to the entropy loss in MD5, the algorithm itself adds characteristics to the output data. Some of these characteristics are compounded in iterative key stretching. Thus it's actually faster to do the key stretching to find the key than building a rainbow table for the last iteration -- the stretching itself helps build the characteristics that lead to hash collisions. If they wanted to slow us down, the morons should have used SHA-512 -- all the hash algorithms are trivial to implement (I've done them all in every language from Assembly to JavaScript in less than a week of evenings).
If you really wanted to deliver some secret code, that targets specific systems, and have it be very tiny to the point of being nearly unnoticeable, then I'd also use return oriented programming.
The spooks ain't spooky enough to be real hackers, IMO.
the virus tries to combine various pairs of %PATH% paths and names from %PROGRAMFILES%
Well then who the fuck cares what the thing does? It's not targeting any systems of any importance. *nix boxen don't use such strings.
Laws, contracts and licenses aren't made of "shoulds"
Actually, they seem quite musty to me.
When you go to a web site that "stores cookies" in your browser, what happens is that a HTTP "Set-Cookie" header is sent to your browser. YOU HAVE THE POWER TO DISABLE COOKIES in your browser. It's not like the remote site can make your browser save the cookie.
The user already has every capability to prevent the remote sites from storing any cookies. Simply DISABLE ALL COOKIES. Then, if you run across a site that has a feature requiring cookies (stateful sessions, like logging in), then and ONLY THEN DO YOU ENABLE COOKIES for that site alone. White list it. Oh your browser doesn't have a white list? YES IT DOES. IE does. FF has the Cookie Monster plugin among other ways, Chrome has -- Fuck Chrome! Chromium Exists. Chrome is closed source and has Google's secret advertising sauce added if you don't like cookies why would you use Chrome?! Google Sells Ads.
Now, being a primordial deep one from time immemorial, I remember an age before cookies existed. I used caller ID, bitrate and handshake timings to log and verify my visitors' identity in the BBS era. Then came the Internet. I used a hash of the user agent, IP address, and other header strings along with URL munging (crazy crap you see after the ? in your address bar) to identify and verify users. Cookies allowed us to stop crapping up every URL on the page, and causing massive link rot... So, you want to make laws about cookies, eh? Well there are levels of tracking we are willing to accept, and we don't even need the damn cookies to do so. Enjoy server side storage of your IP address, browser signatures, and Query Strings cocking up your bullshit European URLs....
Get bent morons. Cookies are good for you, at least YOU can control them. You can't very well control whether or not servers use URL munging....
Surely that's more likely 1700 m/s (meters per second), not miles per second. Though if the latter, sign me up for a test ride!
Well, what if it were 10,221,904.1 furlongs per fortnight? Would you sign up then?
So how does a company control the corp message?
New cover sheets on the TPS reports. Didn't you get the memo?
The problem with petitions and voting is how to trust the counters.
You have to pay for everything in one way or another.
It must suck to get taxed for breathing air. Maybe you shouldn't have taken the advice to "Get your ass to Mars".
"What Happens To Google Employees When They Die?"
They become dead. Next question.
Oh, its actually an article? Well then, it should read: What Happens When Google Employees Die?
Considering it's supposed to be an article instead of a thinly veiled slashvertizement, I still say it's all hogwash; Totally just hypothetical conjecture. No one really knows what will actually happen until we test the hypothesis.
Murder?! NO, Science!
Those are some nice employees you've got there, I'd be a real shame if something happened to them...
Can you please get the webmasters to hash our passwords instead of storing them in the DB in cleartext, and limiting the number and type of characters I can provide? If you work at a bank that already does this, may the gods favor you; Otherwise... Well, at least you have this contingency plan.
We don't have a good term for what Apple does. As you point out, it isn't QUITE trolling since they are producing products. However, they certainly do seem to be employing the same sleezy tactics.
Those sleazy tactics involve weaving a collection of questionable or down right bogus patents into a lawsuit, then casting it any and all opponents in the hopes to hamper them or catch a few who are unable to litigate, thus netting huge settlements. Sounds pretty much like the definition of trolling to me -- Drag-Net is another name for trolling too. Have you ever even been fishing before? Or has the Internet leached away all other reality leaving only it's pedantically demented definition of "troll" in tact and removing any connection to its basis in the aforementioned fishing acts?
I'm a former iPhone user, currently on Android. It's more customizable, all right... but "better"? I would not say that is true for the "normal" user. I'll probably get a Windows phone next
, just to screw around with that... But it has taken me a few months to get it to where I don't feel the need, for example, to download a couple dozen keyboards
until I find one that works as well as the iPhone's.
You are not a "normal" user.