Google has never been the target of a DDOS, where hundreds of thousands of infected computers are trying to cause real financial damage to it. I'm pretty sure they never will be, either. So why should they care? By not using Windows internally they are automatically protected against such attacks.
How, exactly, is "buying software" supposed to stop "customers selling their souls"?
You're not exactly selling your soul. You are only licensing it. Hope your DRM is up to date.
The problem is that nothing is stopping Google from copying your information between devices, unlike DRM.
To be honest, I'd love to have my details protected by some DRM - every time a company makes any use of it, they have to contact my server first and ask for a one-time permission.
Doesn't seem too likely, unfortunately.
I leave wireless webcams in public toilets. They're not called "public" for nothing.
An open window is not called "open" because I invite people to enter my house through it. It's called "open" because that's the adjective that describes it.
To law enforcement agents: I don't really leave wireless webcams in public toilets. They're all wired and I'm sitting in the next cubicle. I'll come out with my hands up now.
I can see how it stops competition. After all, never in the history of computing was there a platform where developers couldn't use the tools of their choice. You need a license from Sony to publish a game, but if I want to hand-code the game in machine code, there's nothing stopping me. If I like assembly language and I write my own assember - so be it. If I have an Ocaml cross compiler - fine. As long as it does the job and reaches the quality measures of the platform. This is the first platform where I'm not allowed to use my own macro assembler or my own port of Ocaml to write an app. So this stops other companies from offering their own tools to the developers. This would be (in a bad car analogy) like Ford saying that if you clean your car with clearing products that were not provided by Ford, you lose your warranty. It does hurt competition.
However, I agree that the proper way to fight these sort of things is just not to play the game. Don't develop for this platform. Just stay away and kill it not by fighting it in court, but by saying "it's just not worth it - cross platform development is much more profitable. See you!"
The truth is that this law saddens me. It's trying to solve a problem using technology. So companies will first get fined and then start encrypting. Woo hoo.
I'd much rather see a law that fined companies for every detail they store unless they could justify why they need to store it, encrypted or not.
I don't want my private details to be stored anywhere just because "that's company policy". I want it to be justified. Yes, if they have to be stored, then they should have to be stored encrypted. But first they must justify why they need my evening phone number, my date of birth, my marital status etc. etc.
How about a database associating car numbers with the address they were last seen at? This is public information - I could walk up and down my street and upload this information, and Google could do it with the information they already have from their travels around the world.
The first problem is that it doesn't guarantee anything. There are very few software companies that close down or get rid of people because of small quirky bugs. You're not going to lose your job simply because you write perfect code either...
The second problem is that if you do keep your job, it's only to maintain the same piece of code. Aren't there more exciting things to do than to fix the same bugs you left in some spaghetti code that only you can understand? Isn't it better to write good solid readable code and move on to more interesting problems than off-by-one bugs you left on purpose?
And the third problem is that you can never justify that to your boss: "You've got to keep me because the code is terrible and only I can maintain it". The easiest thing would be to cut the losses and send you free, only to bring someone who can write some code that isn't an expensive liability.
Sadly, you're not the only person that writes bad code for "job security". So I hope your post gets a "Score: 5 Funny" and not a "Score: 2 Insightful"...
I'm also a Lua fanboy, but for motivation and inspiration I'd use Python and not Lua.
Just think about this problem: how do you get a directory listing in Lua?
Lua doesn't have an immense standard libraries. Even though it's extremely powerful, the power is in the flexibility, not in the environment. Of course, there are many many libraries that you can pretty much download and use (depending on OS, of course), but it still doesn't come "batteries included" like Python.
Also, Lua is very simple to learn, but even then you have to know a bit before you can have some fun. Compare: Lua: for _,v in ipairs(list) Python: for x in list
Even for basic loops you have to call a function.
Compare: Lua: print(string.format("Your age is %d", age)) Python: print("Your age is %d" % age)
Even for basic output you have to call a function.
Lua is fantastic, I've used it in many projects - at work and at home. But in my opinion Python is better for "get something working quickly" (i.e. the modern, much much better, equivalent of BASIC as a first language). As my "scratchpad" / calculator / quick eval-print-loop I always use Python.
It's not a question of maintaining 100 computers for every competeny programmer. It's the price of 100 computers for every script written by a non-programmer. If a script running at 100% CPU takes 12 hours to run, you cannot run 10 such scripts at the same time on the same computer without delaying the result. If your non-programmer writes many scripts your cost spirals out of control. Employing one "scientist" and one "programmer" may be more reasonable.
Not to mention the fact that you may want to package and sell some of these tools, and telling your customers "this thing runs for 12 hours, or you can buy 100 computers" is ridiculous when the alternative is so simple.
The 1400-fold optimisation was the result of not passing huge arrays by value, hoisting expensive calculations out of loops and memoising. I don't think there was any more to it than that - it wasn't exactly "low level" optimisation (I didn't have to rewrite anything in C, for example).
But taking only the first point - if you have a list of 10000 elements and you pass it like this: func(@data) you actually copy 10000 elements. If you pass it like this: func(\@data) you only pass the reference.
Can you believe that the second version works 10000 times faster than the first? Can you see that for a non-programmer the first option is more "straight-forward"? It doesn't take a genius to "optimise" this, but if you've never heard the term "by reference" you may not know any better.
My first task at my previous job was to speed up a perl script that took 12 hours to run. That meant that until you got the results, you were stuck. It meant that "tweaking" the input parameters required a lot of preparation work, or just wasted a huge amount of time.
I didn't know perl, but I knew how to program and how to optimise. It took me two days to learn perl (just enough for the task) and to reduce the runtime to 30 seconds (I was told about the original programmer "he's a scientist, not a programmer"). The result was still written in perl, by the way.
The improvement meant that the script could be used a hundred times a day with different parameters, something that would have taken months. Your suggestion is to buy a thousand machines to crunch the numbers instead of optimising the script. That just doesn't make sense to me.
Slashdot Mirror
ImageMagick is your friend. Feel free to google "imagemagick watermark".
Also:
1. Find new algorithm
2. ???
3. Profit
And:
In Soviet Russia algorithms publish you.
Google has never been the target of a DDOS, where hundreds of thousands of infected computers are trying to cause real financial damage to it. I'm pretty sure they never will be, either. So why should they care? By not using Windows internally they are automatically protected against such attacks.
You mean "it's 1,000 times cheaper than inkjet".
Does anyone else think of Homer Simpson wearing the WWJD bracelet when he sees the initials "WWDC"?
And I also heard that Twin Galaxies don't accept Google Pac-Man high scores. So why bother?
How, exactly, is "buying software" supposed to stop "customers selling their souls"?
You're not exactly selling your soul. You are only licensing it. Hope your DRM is up to date.
The problem is that nothing is stopping Google from copying your information between devices, unlike DRM. To be honest, I'd love to have my details protected by some DRM - every time a company makes any use of it, they have to contact my server first and ask for a one-time permission. Doesn't seem too likely, unfortunately.
It's about Alice Cooper.
"she" is a typo (extra 's').
Bob is Bob Ezrin.
I leave wireless webcams in public toilets. They're not called "public" for nothing.
An open window is not called "open" because I invite people to enter my house through it. It's called "open" because that's the adjective that describes it.
To law enforcement agents: I don't really leave wireless webcams in public toilets. They're all wired and I'm sitting in the next cubicle. I'll come out with my hands up now.
Yes, we really need @gmailwhileitwasinviteonly.com.
I like the funny kind of correct better. It's the best of both worlds.
In other words, "This is not a knife... THIS is a knife".
I can see how it stops competition. After all, never in the history of computing was there a platform where developers couldn't use the tools of their choice. You need a license from Sony to publish a game, but if I want to hand-code the game in machine code, there's nothing stopping me. If I like assembly language and I write my own assember - so be it. If I have an Ocaml cross compiler - fine. As long as it does the job and reaches the quality measures of the platform. This is the first platform where I'm not allowed to use my own macro assembler or my own port of Ocaml to write an app. So this stops other companies from offering their own tools to the developers. This would be (in a bad car analogy) like Ford saying that if you clean your car with clearing products that were not provided by Ford, you lose your warranty. It does hurt competition.
However, I agree that the proper way to fight these sort of things is just not to play the game. Don't develop for this platform. Just stay away and kill it not by fighting it in court, but by saying "it's just not worth it - cross platform development is much more profitable. See you!"
When the URL is http://gdddmfm.eiiwihh817266.ooe7.com
I was absolutely sure RSS was invented exactly for this reason. But then, isn't Facebook just an RSS client with plug-ins, pictures and links?
The truth is that this law saddens me. It's trying to solve a problem using technology. So companies will first get fined and then start encrypting. Woo hoo.
I'd much rather see a law that fined companies for every detail they store unless they could justify why they need to store it, encrypted or not.
I don't want my private details to be stored anywhere just because "that's company policy". I want it to be justified. Yes, if they have to be stored, then they should have to be stored encrypted. But first they must justify why they need my evening phone number, my date of birth, my marital status etc. etc.
Alice couldn't help smiling as she took out her memorandum- book, and worked the sum for him:
365
- 1
-----
364
Humpty Dumpty took the book, and looked at it carefully. `That seems to be done right -- ' he began.
`You're holding it upside down!' Alice interrupted.
Your face is also public. So are your fingerprints. Unless you wear a mask and gloves everywhere you go, in which case you're under arrest.
How about a database associating car numbers with the address they were last seen at? This is public information - I could walk up and down my street and upload this information, and Google could do it with the information they already have from their travels around the world.
If you don't like it, use public transport.
I hope you're not serious.
The first problem is that it doesn't guarantee anything. There are very few software companies that close down or get rid of people because of small quirky bugs. You're not going to lose your job simply because you write perfect code either...
The second problem is that if you do keep your job, it's only to maintain the same piece of code. Aren't there more exciting things to do than to fix the same bugs you left in some spaghetti code that only you can understand? Isn't it better to write good solid readable code and move on to more interesting problems than off-by-one bugs you left on purpose?
And the third problem is that you can never justify that to your boss: "You've got to keep me because the code is terrible and only I can maintain it". The easiest thing would be to cut the losses and send you free, only to bring someone who can write some code that isn't an expensive liability.
Sadly, you're not the only person that writes bad code for "job security". So I hope your post gets a "Score: 5 Funny" and not a "Score: 2 Insightful"...
When you were longer?
;-)
Hmmm...
I'm also a Lua fanboy, but for motivation and inspiration I'd use Python and not Lua.
Just think about this problem: how do you get a directory listing in Lua?
Lua doesn't have an immense standard libraries. Even though it's extremely powerful, the power is in the flexibility, not in the environment. Of course, there are many many libraries that you can pretty much download and use (depending on OS, of course), but it still doesn't come "batteries included" like Python.
Also, Lua is very simple to learn, but even then you have to know a bit before you can have some fun. Compare:
Lua: for _,v in ipairs(list)
Python: for x in list
Even for basic loops you have to call a function.
Compare:
Lua: print(string.format("Your age is %d", age))
Python: print("Your age is %d" % age)
Even for basic output you have to call a function.
Lua is fantastic, I've used it in many projects - at work and at home. But in my opinion Python is better for "get something working quickly" (i.e. the modern, much much better, equivalent of BASIC as a first language). As my "scratchpad" / calculator / quick eval-print-loop I always use Python.
If he can publish anything, even a Tetris clone would be better than what we have at the moment...
"Duke Nukem Forever: Attack of the Tetrominoes"
It's not a question of maintaining 100 computers for every competeny programmer. It's the price of 100 computers for every script written by a non-programmer. If a script running at 100% CPU takes 12 hours to run, you cannot run 10 such scripts at the same time on the same computer without delaying the result. If your non-programmer writes many scripts your cost spirals out of control. Employing one "scientist" and one "programmer" may be more reasonable.
Not to mention the fact that you may want to package and sell some of these tools, and telling your customers "this thing runs for 12 hours, or you can buy 100 computers" is ridiculous when the alternative is so simple.
The 1400-fold optimisation was the result of not passing huge arrays by value, hoisting expensive calculations out of loops and memoising. I don't think there was any more to it than that - it wasn't exactly "low level" optimisation (I didn't have to rewrite anything in C, for example).
But taking only the first point - if you have a list of 10000 elements and you pass it like this:
func(@data)
you actually copy 10000 elements. If you pass it like this:
func(\@data)
you only pass the reference.
Can you believe that the second version works 10000 times faster than the first? Can you see that for a non-programmer the first option is more "straight-forward"? It doesn't take a genius to "optimise" this, but if you've never heard the term "by reference" you may not know any better.
That's just not true.
My first task at my previous job was to speed up a perl script that took 12 hours to run. That meant that until you got the results, you were stuck. It meant that "tweaking" the input parameters required a lot of preparation work, or just wasted a huge amount of time.
I didn't know perl, but I knew how to program and how to optimise. It took me two days to learn perl (just enough for the task) and to reduce the runtime to 30 seconds (I was told about the original programmer "he's a scientist, not a programmer"). The result was still written in perl, by the way.
The improvement meant that the script could be used a hundred times a day with different parameters, something that would have taken months. Your suggestion is to buy a thousand machines to crunch the numbers instead of optimising the script. That just doesn't make sense to me.