And then he has to persuade someone to take the bet. You can sure that betting establishments will pay someone to work out the odds at least as well as he does. It's okay for informal betting among friends, but if you're trying to make money then fleecing your friends only works a few times before you run out of friends...
I've written articles on my Nokia 770 with a bluetooth keyboard. It happens, and it's convenient because I can stick both the device and the keyboard in a jacket pocket. That doesn't mean that they replace a laptop for me.
I would suspect that the majority of open source projects and open source contributions are in a fourth category: the goal is to have working software because we need it. The code is released under an open license because it costs less to develop it if other people help (and it costs a lot less for two or more groups that have largely overlapping sets of requirements to cooperate on a single implementation than to each create their own).
I've said it before and I'll say it again: Support does not mean being a substitute for documentation. Support means adding features. You don't pay to have someone hold your hand (well, you may pay for training, but that's a different issue), you pay so that the features that you want added and the bugs that you want fixed get the highest priority.
The problem is that what you think support means is not the same as what support means to the people making money from free software. Pretty much all of the code that I write is free software, which means that the customer has the right to use, modify, and redistribute it. Most of it is BSD licensed, and most of it is publicly released.
Support does not mean answering a telephone and helping users with their problems. Support means fixing bugs and adding new features. There are a lot of users who are happy with the code in its existing state - these can be cheapskates because they gain nothing from improving it. But there are also always people who need more from a piece of software. These are the ones that need to pay for support. And, in my experience, they don't 'dicker over every hour' because even the amount that I charge is less than the value that they get from the software. If something is important to your business, you don't cut costs in maintaining it - the businesses that do don't stay around for very long (unless they're bailed out by government subsidies).
Creating software is hard. Copying software is easy. Yet somehow a lot of people seem convinced that it makes economic sense to create software for free and then charge for copying it.
I've mentored a few GSoC students and among the ones I've mentored and the other ones on the same project, the best successes that we've seen have been people with a prior involvement with the project. The GSoC[1] really isn't long enough if you need to spend 2-3 weeks getting to know your way around the code. If you're serious about it, get involved with the project six months earlier, poke at the code, and send a couple of patches. Then you can actually accomplish something in the GSoC time.
[1] Especially with its inflexibility with dates, meaning that non-US students often start a week or two later and have another week or two to go by the 'pens down' date.
Shame you're posting at 0. If you aren't a great coder, read some existing code and document what it does. If you don't understand it, probably the next person along won't either. Find the person who wrote it and get them to give you a quick explanation, then write up that explanation in more details. Add doxygen comments. This is also a great way of learning a new codebase. If you think something is wrong, ask - you may have just spotted a bug.
Beyond that, look at the bug tracking system. See if you can reproduce bugs. If you can, try to produce a reduced test case. Detailed bug reports are incredibly valuable. Taking a bug report that says 'foo doesn't work' and saying 'when given X input, foo crashes with this stack trace. Valgrind output is {attached}. Problem appears to be in bar.c, but I don't know enough to fix it.' is amazingly valuable. Even just looking at the bugs, working out which person is most likely to be able to fix it, and making sure that they are aware of the bug is helpful. One of the best things about LLVM's development model is that when someone files a bug related to my code it gets assigned to me quickly, so I don't have to spend any time reading bug reports - ones I am likely to be able / wiling to fix are emailed to me automatically. This only happens because people are paid to do it. On other projects, volunteers who are willing to do this (tedious) work are worth their weight in gold.
There are a great many things wrong with Slashdot's comments system, which makes it all the more surprising that everyone else seems to manage to implement something even worse...
Heh. That would be more fun. They actually do have a pretty large Smalltalk team though. If you got to a Smalltalk conference you'll meet a lot of them.
Have you ever tried working at night, and sleeping during the day?
I find I'm often at my most productive between midnight and 2am. I know other people who achieve the most between 6 and 8am. Make either of us work 9-5 and you're getting some of our least productive hours.
I take it you don't remember the mid to late '90s. Whether a game would actually work with your graphics card was a crapshoot. Typically the system requirements would list half a dozen supported cards. If you had something else, then it might work, or it might not. Microsoft addressed this in later versions of Direct3D by mandating a set of features that must be implemented in hardware for each version, so as long as you had a DirectX >= n card, you could run a DirectX n game.
It's more true of Smalltalk than Erlang. Erlang still has the edit-compile-load cycle. In Smalltalk, you modify objects on the fly. In a traditional Smalltalk system there's no distinction between source code and compiled code. You modify objects by sending messages to them.
Not sure why you'd think Lisp or Smalltalk are write-only. Smalltalk is heavily used in the financial industry specifically because it is easy to quickly make significant changes to legacy code.
Yes, if only there were existing systems that worked that way. Such as the Lisp environment from 1958 or the Smalltalk environment from 1976. Such revolutionary new ideas about programming! I wonder if he will invent automatic refactoring tools next...
I work on a compiler used in HPC. I know a fair amount about SPEC benchmarks and how little they're trusted outside of dick waving lists.
you wouldn't be making such a silly claim of a single Adobe filter being faster on one platform and trying to make the claim of winning the speed contest.
In the compiler world, we say that there is only one benchmark that really matters: your code. Apple's core market at that time was people running the Adobe creative suite. This suite ran faster on Macs than on Windows. Whether that was due to the processor, the compiler, or better code, is irrelevant to the user. The user cares about how much this expensive purchase will allow them to earn.
Different markets. Apple sells locked down devices to consumers. nVidia doesn't even provide their OEM customers with the specs required to write drivers. They either use an nVidia-blessed driver, or none at all. If nVidia decides to stop supporting your tablet, then you can't even complain to the manufacturer about the lack of driver updates (which, given the number of security holes in nVidia drivers in the past, can be important), because they can't do anything about it.
Patronage still exists, and indeed is how most creative works are funded. It's just that now the patrons are not kings, they're publishers. They give creative people an interest free loan to fund the cost of creating the work, and then they own it. The only difference now is cutting out the middlemen.
SPEC benchmarks are irrelevant to most users (they're actually irrelevant to most HPC users too - they're for dick waving, not for anything else). Important benchmarks are things like comparing complex Adobe Photoshop filter application times, because that's what translates to real money for users. Time spent waiting for the computer to do things is time spent not getting anything done that you get paid for. And these benchmarks were verified by other people.
As I said in my post, a lot of the difference was due to the fact that Apple made it easy for people to use AltiVec on MacOS (including providing things like the Accelerate framework, that implemented a lot of common signal processing algorithms for you), while using SSE on Windows was a lot harder and rarer. AltiVec code was at least a factor of 4 faster than x87 code, often more.
Just ask Intel about Apple's benchmarking strategy: For years, the finest in graphic design publicly asserted that PPC was so bitchin' that it was pretty much just letting Intel and x86 live because killing your inferiors is bad taste. Then, one design win, and x86 is suddenly eleventy-billion percent faster than that old-and-busted PPC legacy crap.
This wasn't totally misleading. The G4 was slightly faster than equivalent Intel chips when it was launched and AltiVec was a lot better than SSE for a lot of things. More importantly, AltiVec was actually used, while a lot of x86 code was still compiled using scalar x87 floating point stuff. Things like video editing - which Apple benchmarked - were a lot faster on PowerPC because of this. It didn't matter that hand-optimised code for x86 could often beat hand-optimised code for PowerPC, it mattered that code people were actually running was faster on PowerPC. After about 800MHz, the G4 didn't get much by way of improvements and the G5, while a nice chip, was expensive and used too much power for portables. The Pentium M was starting to push ahead of the PowerPC chips Apple was using in portables (which got a tiny speed bump but nothing amazing) and the Core widened the gap. By the Core 2, the gap was huge.
It wasn't just one design win, it was that the PowerPC chips for mobile were designs that competed well with the P2 and P3, but were never improved beyond that. The last few speedbumps were so starved for memory bandwidth that they came with almost no performance increase. Between the P3 and the Core 2, Intel had two complete microarchitecture designs and one partial redesign. Freescale had none and IBM wasn't interested in chips for laptops.
I didn't know the PowerVR chips were still around.
PowerVR has been doing very well in mobile devices for years. ARM's Mali is just starting to take away some market share from them, but before that most ARM SoCs came with a PowerVR GPU. Like ARM, they license the designs to anyone willing to pay, so if you want to make a SoC then a PowerVR GPU was an obvious choice - nVidia only uses the Tegra GPUs in their own chips, they don't license them. Now it's a less obvious choice, because you can license both CPU and GPU designs from ARM and the latest Mali stuff is pretty nice - full OpenCL support (not just the mobile profile).
Thank God I focus on business programming, not video games. I've yet to hear of ANY tablet or smartphone having problems displaying graphs and charts.
What about 3D transition effects for presentation software? 3D data visualisation? Augmented reality?
Slashdot Mirror
Wrong agency. The CIA has ties to Facebook, the NSA has ties to Google.
And then he has to persuade someone to take the bet. You can sure that betting establishments will pay someone to work out the odds at least as well as he does. It's okay for informal betting among friends, but if you're trying to make money then fleecing your friends only works a few times before you run out of friends...
I've written articles on my Nokia 770 with a bluetooth keyboard. It happens, and it's convenient because I can stick both the device and the keyboard in a jacket pocket. That doesn't mean that they replace a laptop for me.
But since it's easier to fuck people for money
I don't think you need a law degree for that...
I would suspect that the majority of open source projects and open source contributions are in a fourth category: the goal is to have working software because we need it. The code is released under an open license because it costs less to develop it if other people help (and it costs a lot less for two or more groups that have largely overlapping sets of requirements to cooperate on a single implementation than to each create their own).
I've said it before and I'll say it again: Support does not mean being a substitute for documentation. Support means adding features. You don't pay to have someone hold your hand (well, you may pay for training, but that's a different issue), you pay so that the features that you want added and the bugs that you want fixed get the highest priority.
The problem is that what you think support means is not the same as what support means to the people making money from free software. Pretty much all of the code that I write is free software, which means that the customer has the right to use, modify, and redistribute it. Most of it is BSD licensed, and most of it is publicly released.
Support does not mean answering a telephone and helping users with their problems. Support means fixing bugs and adding new features. There are a lot of users who are happy with the code in its existing state - these can be cheapskates because they gain nothing from improving it. But there are also always people who need more from a piece of software. These are the ones that need to pay for support. And, in my experience, they don't 'dicker over every hour' because even the amount that I charge is less than the value that they get from the software. If something is important to your business, you don't cut costs in maintaining it - the businesses that do don't stay around for very long (unless they're bailed out by government subsidies).
Creating software is hard. Copying software is easy. Yet somehow a lot of people seem convinced that it makes economic sense to create software for free and then charge for copying it.
[1] Especially with its inflexibility with dates, meaning that non-US students often start a week or two later and have another week or two to go by the 'pens down' date.
Shame you're posting at 0. If you aren't a great coder, read some existing code and document what it does. If you don't understand it, probably the next person along won't either. Find the person who wrote it and get them to give you a quick explanation, then write up that explanation in more details. Add doxygen comments. This is also a great way of learning a new codebase. If you think something is wrong, ask - you may have just spotted a bug.
Beyond that, look at the bug tracking system. See if you can reproduce bugs. If you can, try to produce a reduced test case. Detailed bug reports are incredibly valuable. Taking a bug report that says 'foo doesn't work' and saying 'when given X input, foo crashes with this stack trace. Valgrind output is {attached}. Problem appears to be in bar.c, but I don't know enough to fix it.' is amazingly valuable. Even just looking at the bugs, working out which person is most likely to be able to fix it, and making sure that they are aware of the bug is helpful. One of the best things about LLVM's development model is that when someone files a bug related to my code it gets assigned to me quickly, so I don't have to spend any time reading bug reports - ones I am likely to be able / wiling to fix are emailed to me automatically. This only happens because people are paid to do it. On other projects, volunteers who are willing to do this (tedious) work are worth their weight in gold.
Solution: choice of view ... but the default should be threaded.
Doesn't work. People in non-threaded view just reply at the top level, making the threaded view degenerate into the non-threaded one.
There are a great many things wrong with Slashdot's comments system, which makes it all the more surprising that everyone else seems to manage to implement something even worse...
Heh. That would be more fun. They actually do have a pretty large Smalltalk team though. If you got to a Smalltalk conference you'll meet a lot of them.
No, even this technology will not address the problem of crappy movies.
Have you ever tried working at night, and sleeping during the day?
I find I'm often at my most productive between midnight and 2am. I know other people who achieve the most between 6 and 8am. Make either of us work 9-5 and you're getting some of our least productive hours.
I take it you don't remember the mid to late '90s. Whether a game would actually work with your graphics card was a crapshoot. Typically the system requirements would list half a dozen supported cards. If you had something else, then it might work, or it might not. Microsoft addressed this in later versions of Direct3D by mandating a set of features that must be implemented in hardware for each version, so as long as you had a DirectX >= n card, you could run a DirectX n game.
I periodically get asked by JP Morgan if I want to come and work on the Smalltalk system that feeds all of their other in-house software.
It's more true of Smalltalk than Erlang. Erlang still has the edit-compile-load cycle. In Smalltalk, you modify objects on the fly. In a traditional Smalltalk system there's no distinction between source code and compiled code. You modify objects by sending messages to them.
Not sure why you'd think Lisp or Smalltalk are write-only. Smalltalk is heavily used in the financial industry specifically because it is easy to quickly make significant changes to legacy code.
Yes, if only there were existing systems that worked that way. Such as the Lisp environment from 1958 or the Smalltalk environment from 1976. Such revolutionary new ideas about programming! I wonder if he will invent automatic refactoring tools next...
If you knew anything about specbenchmarks
I work on a compiler used in HPC. I know a fair amount about SPEC benchmarks and how little they're trusted outside of dick waving lists.
you wouldn't be making such a silly claim of a single Adobe filter being faster on one platform and trying to make the claim of winning the speed contest.
In the compiler world, we say that there is only one benchmark that really matters: your code. Apple's core market at that time was people running the Adobe creative suite. This suite ran faster on Macs than on Windows. Whether that was due to the processor, the compiler, or better code, is irrelevant to the user. The user cares about how much this expensive purchase will allow them to earn.
Different markets. Apple sells locked down devices to consumers. nVidia doesn't even provide their OEM customers with the specs required to write drivers. They either use an nVidia-blessed driver, or none at all. If nVidia decides to stop supporting your tablet, then you can't even complain to the manufacturer about the lack of driver updates (which, given the number of security holes in nVidia drivers in the past, can be important), because they can't do anything about it.
Patronage still exists, and indeed is how most creative works are funded. It's just that now the patrons are not kings, they're publishers. They give creative people an interest free loan to fund the cost of creating the work, and then they own it. The only difference now is cutting out the middlemen.
SPEC benchmarks are irrelevant to most users (they're actually irrelevant to most HPC users too - they're for dick waving, not for anything else). Important benchmarks are things like comparing complex Adobe Photoshop filter application times, because that's what translates to real money for users. Time spent waiting for the computer to do things is time spent not getting anything done that you get paid for. And these benchmarks were verified by other people.
As I said in my post, a lot of the difference was due to the fact that Apple made it easy for people to use AltiVec on MacOS (including providing things like the Accelerate framework, that implemented a lot of common signal processing algorithms for you), while using SSE on Windows was a lot harder and rarer. AltiVec code was at least a factor of 4 faster than x87 code, often more.
Just ask Intel about Apple's benchmarking strategy: For years, the finest in graphic design publicly asserted that PPC was so bitchin' that it was pretty much just letting Intel and x86 live because killing your inferiors is bad taste. Then, one design win, and x86 is suddenly eleventy-billion percent faster than that old-and-busted PPC legacy crap.
This wasn't totally misleading. The G4 was slightly faster than equivalent Intel chips when it was launched and AltiVec was a lot better than SSE for a lot of things. More importantly, AltiVec was actually used, while a lot of x86 code was still compiled using scalar x87 floating point stuff. Things like video editing - which Apple benchmarked - were a lot faster on PowerPC because of this. It didn't matter that hand-optimised code for x86 could often beat hand-optimised code for PowerPC, it mattered that code people were actually running was faster on PowerPC. After about 800MHz, the G4 didn't get much by way of improvements and the G5, while a nice chip, was expensive and used too much power for portables. The Pentium M was starting to push ahead of the PowerPC chips Apple was using in portables (which got a tiny speed bump but nothing amazing) and the Core widened the gap. By the Core 2, the gap was huge.
It wasn't just one design win, it was that the PowerPC chips for mobile were designs that competed well with the P2 and P3, but were never improved beyond that. The last few speedbumps were so starved for memory bandwidth that they came with almost no performance increase. Between the P3 and the Core 2, Intel had two complete microarchitecture designs and one partial redesign. Freescale had none and IBM wasn't interested in chips for laptops.
I didn't know the PowerVR chips were still around.
PowerVR has been doing very well in mobile devices for years. ARM's Mali is just starting to take away some market share from them, but before that most ARM SoCs came with a PowerVR GPU. Like ARM, they license the designs to anyone willing to pay, so if you want to make a SoC then a PowerVR GPU was an obvious choice - nVidia only uses the Tegra GPUs in their own chips, they don't license them. Now it's a less obvious choice, because you can license both CPU and GPU designs from ARM and the latest Mali stuff is pretty nice - full OpenCL support (not just the mobile profile).
Thank God I focus on business programming, not video games. I've yet to hear of ANY tablet or smartphone having problems displaying graphs and charts.
What about 3D transition effects for presentation software? 3D data visualisation? Augmented reality?