> This is not going to be something that will catch on quickly, > or even at all. How many people are going to rush out there to > get one of these? Not many.
I probably will, for one. I'm less interested in the iTunes aspect, but hopeful that the phone will have a better user interface than existing phones, and of course Bluetooth syncing for iSync.
> Most people already have cell phones
Do they? Google sources claim about 50% of Americans have cell phones. Judging by countries like Japan where cell phone ownership is ~ 90%, there's a lot of room to grow in the US.
> and will have to wait till > their service contract is up to get a new phone, unless there is > a promotion to get people to start using them.
Cell phone contracts are typically one year, sometimes two. Google sources say 25% of owners switch carriers after their contract expires. That's a lot of opportunity.
You claim you buy a cell phone every year. That's probably more turnover than iPods!
> And how much > is this going to cost? Right now iPods sell for $200+ and a > new cell phone with the features that will allow you to support > the software needed are $250 retail.
iPods start at $99, not $200. And I don't see what the problem is. My cell phone would have cost ~ $200, but with the contract I ended up paying $40 or so.
Your math is wonky. An iPod costs $200, a cell phone costs $250, so a hybrid would cost $450? That's clearly bogus.
> Either their attempt at protecting OS X fails (see above for why this is inevitable)
So what if it does? What percentage of people are going to use a hacked version? What percentage of those represent lost hardware sales, and what percent represents gained software sales? How does a hacked version of OS X "put Apple completely out of the hardware business?"
> First, downloaded files should, by default, not be opened
> automatically. If the user wishes to change this setting, it's
> the user's responsibility.
This is a huge usability problem for people who aren't good at locating the files they download. You have to weigh their needs against security concerns. Only opening "safe" files is an excellent compromise.
> Second, any downloaded files, bundles, scripts, etc., should
> not have the execute bit set by default. When the user tries to
> run it for the first time,
What does setting the execute bit have to do with anything? OS X already pops up a warning when you run a program for the first time.
> OS X will ask for the password, like it does when you install
> X11 or Final Cut or something. Only then will the execute bit
> be set.
This is a VERY VERY BAD IDEA. If I am used to typing in my password every time I download CheckMyStocks.widget, I'll stop caring when I have to type in my password; I've just become more vulnerable to seriously malcious scripts that want to erase my hard drive instead of delete my home directory.
> This is not a small inconvenience; rather, it is a huge
> convenience. Sure, you have to type a password to run a
> downloaded program for the first time, but that's only as
> annoying as finding out the bank put an extra $10,000 in your
> account by mistake.
I don't understand your metaphor at all. A better one would be giving your social security number every time you use your credit card. Sure, you might stop a few people with stolen cards, but you'll be so used to giving out your SSNs that you'll miss the person who asks for it and then proceeds to take out a mortgage in your name.
> And your computer won't suddenly acquire programs
> spyware/malware/adware/viruses and other nice stuff that
> you didn't intend it to acquire.
In your example, you may accidentally download files, but they won't run until you type in your password. Currently, you can accidentally download files, but they won't run until you actually execute them (in Dashboard, by dragging them onto the screen). Your solution is less convenient without providing any more safeguards, and less secure because the user becomes accustomed to providing their password unnecessarily.
> This is extremely convenient. It's an additional level of security
> for safety-conscious parents who use Tiger's new child-safety
> features. It's good for owners of computers with multiple
> users, who don't want people to run arbitrary code that came
> from God knows where.
The Security system preference pane does this already.
> Apple could and should take this a step further. At some
> point, people will find ways to screw up Macs with programs
> spyware/malware/adware/viruses, especially if they become
> pretty popular. Apple could prevent this before it happens.
> Provide an online database of MD5 sums of binaries for OS X,
> and provide a mechanism in the OS to report bad software
> and where it came from.
This will not work because of prebinding. Your executables have a different md5 sum than mine.
It's more difficult to turn this buffer overflow into arbitrary code execution on PowerPC because the link register isn't spilled to the stack (so you have to overwrite some function's return address higher up in the call chain) which takes more work and requires a larger payload, larger instruction sizes means you need a still larger payload, larger instruction sizes mean it's trickier to build an instruction stream with no zero bytes, and in any case you may have to flush the instruction cache to force it to see your changes - no easy task.
Leaf functions, functions that take advantage of tail-call optimizations, and functions that move the link register into a GPR rather than the stack don't let you overwrite the return address at all, which is never the case on x86.
This guy claims that he can't tell us how many petabytes it would take to store a lookup table because *Excel* barfs when he tries to calculate a number that big?
Guess he missed the memo: Excel is Not a Calculator
95 printable ASCII characters plus one for a blank, 42 characters long ->
dc 95 1 + 42 ^ p 18004944527338309981576108909056723035465779772 627 3256603133867323648139554786902016
but all too often it is. Look at C#: its notion of "partial classes" exists for no reason other than to support Microsoft's code generating form painter.
Dependence on tools signals a weakness in the language. The solution is not to increase the accessibility of the language to the tools; this is addressing the symptoms rather than the cause. The proper solution is to identify weakness in the language that the tools are trying to fix and then invent language constructs to address those problems.
Oh, and make the constructs as general as possible to avoid undue pollution of the language. Compare the author's example, Java's ultra-specific @Remote, to Objective-C's notion of forwarding, which allows for transparent remoting without any code generation (and has plenty of other uses too!)
Can you tell me how to make it work, then? Because I can't.
I created a file called "first.txt" and put the phrase "bicycle turpentine" in it. I searched for "bicycle" and Google found it. I then changed the contents of the file to "aardvark turpentine" and searched for "bicycle" again. Google found the same file: it was not aware of the change. I then renamed the file to "second.txt" and repeated the search, and Google found "first.txt." That is, it found a file which doesn't exist which, even if it did exist, wouldn't contain the word that I searched for!
I then searched for "turpentine" and Google found both first.txt and second.txt, even though second.txt is first.txt renamed!
The major problem with all these search tools is that none of them actually update when you change a file. They only update when they reindex. In that sense, they're no better than a GUI on top of slocate.
Only Apple's search tool (and WinFS, if it ever appears) does the live updating.
If you're using AllOfMp3, you might as well be pirating the songs for all the money that the artists receive. Presumably, Mindawn receives the artists' permissions to sell their music.
I installed it and left my machine alone for three hours. Upon returning, I created a text file and added the text "bicycle" to it, saved it to my desktop, then tried to find bicycle. It didn't find it. Then I renamed the file to "bicycle" and searched for bicycle again, and it didn't find it.
Does this thing not do live updates? If it searches what it knew about after the last index, it's no better than locate.
We don't demand that every e-mail we receive from a company be typed by hand. (Would we really want Amazon to hand-type our order confirmations?) Why demand it for the phone?
When I have an overdue library book, the library automatically calls me to let me know. This is a great use of an automated phone recording system.
I recognize there is a potential for abuse, but preventing all recorded phone calls is a far too broad solution. Limiting what a qualifies as a "business relationship" makes more sense.
Re:Should be titled "Holub on Java Patterns"
on
Holub on Patterns
·
· Score: 2, Insightful
Patterns are often applied as a substitute for missing language features. Using the Decorator pattern makes little sense if you can add methods and variables to individual objects (like in Python or Self).
Should be titled "Holub on Java Patterns"
on
Holub on Patterns
·
· Score: 4, Insightful
The dirty unacknowledged secret of design patterns is that they're strongly coupled to a language. For example, switching from a statically typed language like Java to a dynamic one with forwarding substantially changes the approach to Factory, Proxy, Singleton, Observer and others. In fact, they're often rendered trivial.
The claim that the approaches described in the book apply to any language is just not true. These patterns are for Java and Java-like languages.
Slashdot Mirror
> This is not going to be something that will catch on quickly,
> or even at all. How many people are going to rush out there to
> get one of these? Not many.
I probably will, for one. I'm less interested in the iTunes aspect, but hopeful that the phone will have a better user interface than existing phones, and of course Bluetooth syncing for iSync.
> Most people already have cell phones
Do they? Google sources claim about 50% of Americans have cell phones. Judging by countries like Japan where cell phone ownership is ~ 90%, there's a lot of room to grow in the US.
> and will have to wait till
> their service contract is up to get a new phone, unless there is
> a promotion to get people to start using them.
Cell phone contracts are typically one year, sometimes two. Google sources say 25% of owners switch carriers after their contract expires. That's a lot of opportunity.
You claim you buy a cell phone every year. That's probably more turnover than iPods!
> And how much
> is this going to cost? Right now iPods sell for $200+ and a
> new cell phone with the features that will allow you to support
> the software needed are $250 retail.
iPods start at $99, not $200. And I don't see what the problem is. My cell phone would have cost ~ $200, but with the contract I ended up paying $40 or so.
Your math is wonky. An iPod costs $200, a cell phone costs $250, so a hybrid would cost $450? That's clearly bogus.
> Either their attempt at protecting OS X fails (see above for why this is inevitable)
So what if it does? What percentage of people are going to use a hacked version? What percentage of those represent lost hardware sales, and what percent represents gained software sales? How does a hacked version of OS X "put Apple completely out of the hardware business?"
> First, downloaded files should, by default, not be opened > automatically. If the user wishes to change this setting, it's > the user's responsibility. This is a huge usability problem for people who aren't good at locating the files they download. You have to weigh their needs against security concerns. Only opening "safe" files is an excellent compromise. > Second, any downloaded files, bundles, scripts, etc., should > not have the execute bit set by default. When the user tries to > run it for the first time, What does setting the execute bit have to do with anything? OS X already pops up a warning when you run a program for the first time. > OS X will ask for the password, like it does when you install > X11 or Final Cut or something. Only then will the execute bit > be set. This is a VERY VERY BAD IDEA. If I am used to typing in my password every time I download CheckMyStocks.widget, I'll stop caring when I have to type in my password; I've just become more vulnerable to seriously malcious scripts that want to erase my hard drive instead of delete my home directory. > This is not a small inconvenience; rather, it is a huge > convenience. Sure, you have to type a password to run a > downloaded program for the first time, but that's only as > annoying as finding out the bank put an extra $10,000 in your > account by mistake. I don't understand your metaphor at all. A better one would be giving your social security number every time you use your credit card. Sure, you might stop a few people with stolen cards, but you'll be so used to giving out your SSNs that you'll miss the person who asks for it and then proceeds to take out a mortgage in your name. > And your computer won't suddenly acquire programs > spyware/malware/adware/viruses and other nice stuff that > you didn't intend it to acquire. In your example, you may accidentally download files, but they won't run until you type in your password. Currently, you can accidentally download files, but they won't run until you actually execute them (in Dashboard, by dragging them onto the screen). Your solution is less convenient without providing any more safeguards, and less secure because the user becomes accustomed to providing their password unnecessarily. > This is extremely convenient. It's an additional level of security > for safety-conscious parents who use Tiger's new child-safety > features. It's good for owners of computers with multiple > users, who don't want people to run arbitrary code that came > from God knows where. The Security system preference pane does this already. > Apple could and should take this a step further. At some > point, people will find ways to screw up Macs with programs > spyware/malware/adware/viruses, especially if they become > pretty popular. Apple could prevent this before it happens. > Provide an online database of MD5 sums of binaries for OS X, > and provide a mechanism in the OS to report bad software > and where it came from. This will not work because of prebinding. Your executables have a different md5 sum than mine.
Dashboard widgets are not .apps. They're a lot closer to HTML files.
> The stack behaviour of PowerPC is just as
> predictable as x86, and it's just as easy to
> perform a buffer overflow attack on vulnerable
> code.
No it's not.
For example, here's a function vulnerable to a classic buffer overflow:
void security_hole(char* s) {
char buff[128], *ptr = buff;
while (*s++ = *buff++);
}
It's more difficult to turn this buffer overflow into arbitrary code execution on PowerPC because the link register isn't spilled to the stack (so you have to overwrite some function's return address higher up in the call chain) which takes more work and requires a larger payload, larger instruction sizes means you need a still larger payload, larger instruction sizes mean it's trickier to build an instruction stream with no zero bytes, and in any case you may have to flush the instruction cache to force it to see your changes - no easy task.
Leaf functions, functions that take advantage of tail-call optimizations, and functions that move the link register into a GPR rather than the stack don't let you overwrite the return address at all, which is never the case on x86.
Google's Gmail runs on Xserves.
So why not buy a Mac with Linux pre-installed?
>Because I can run down to Frys and for ~the price of a cute
> little mini-me-too, I can build a 2.5 Ghz 64 bit box/
> 120G HD/512M ram/
I call bull. A 2.5 GHz Athlon 64 processor alone costs about what a Mac Mini costs, let alone all the other stuff.
> Wide choice of video cards that could
> actually push HD video to my TV, and run MythTV.
The high end Mac Mini can do 720p HD TV. See http://www.osxhax.com/archives/000063.html
This guy claims that he can't tell us how many petabytes it would take to store a lookup table because *Excel* barfs when he tries to calculate a number that big?
2 627 3256603133867323648139554786902016
Guess he missed the memo: Excel is Not a Calculator
95 printable ASCII characters plus one for a blank, 42 characters long ->
dc
95 1 + 42 ^ p
1800494452733830998157610890905672303546577977
which is about 10^68 petabytes.
That wasn't so hard now, was it?
Running Linux on the Mac does not require "emulation."
but all too often it is. Look at C#: its notion of "partial classes" exists for no reason other than to support Microsoft's code generating form painter.
Dependence on tools signals a weakness in the language. The solution is not to increase the accessibility of the language to the tools; this is addressing the symptoms rather than the cause. The proper solution is to identify weakness in the language that the tools are trying to fix and then invent language constructs to address those problems.
Oh, and make the constructs as general as possible to avoid undue pollution of the language. Compare the author's example, Java's ultra-specific @Remote, to Objective-C's notion of forwarding, which allows for transparent remoting without any code generation (and has plenty of other uses too!)
Can you tell me how to make it work, then? Because I can't.
I created a file called "first.txt" and put the phrase "bicycle turpentine" in it. I searched for "bicycle" and Google found it. I then changed the contents of the file to "aardvark turpentine" and searched for "bicycle" again. Google found the same file: it was not aware of the change. I then renamed the file to "second.txt" and repeated the search, and Google found "first.txt." That is, it found a file which doesn't exist which, even if it did exist, wouldn't contain the word that I searched for!
I then searched for "turpentine" and Google found both first.txt and second.txt, even though second.txt is first.txt renamed!
So how do I make Google actually do live updates?
Apple's Spotlight engine is pluggable. You write a simple "sniffer" program and suddenly you can search that sort of file.
The major problem with all these search tools is that none of them actually update when you change a file. They only update when they reindex. In that sense, they're no better than a GUI on top of slocate. Only Apple's search tool (and WinFS, if it ever appears) does the live updating.
If you're using AllOfMp3, you might as well be pirating the songs for all the money that the artists receive. Presumably, Mindawn receives the artists' permissions to sell their music.
I installed it and left my machine alone for three hours. Upon returning, I created a text file and added the text "bicycle" to it, saved it to my desktop, then tried to find bicycle. It didn't find it. Then I renamed the file to "bicycle" and searched for bicycle again, and it didn't find it. Does this thing not do live updates? If it searches what it knew about after the last index, it's no better than locate.
If your "target" is merely multicore chips, IBM's had it for a while with the POWER4.
We don't demand that every e-mail we receive from a company be typed by hand. (Would we really want Amazon to hand-type our order confirmations?) Why demand it for the phone? When I have an overdue library book, the library automatically calls me to let me know. This is a great use of an automated phone recording system. I recognize there is a potential for abuse, but preventing all recorded phone calls is a far too broad solution. Limiting what a qualifies as a "business relationship" makes more sense.
Patterns are often applied as a substitute for missing language features. Using the Decorator pattern makes little sense if you can add methods and variables to individual objects (like in Python or Self).
The dirty unacknowledged secret of design patterns is that they're strongly coupled to a language. For example, switching from a statically typed language like Java to a dynamic one with forwarding substantially changes the approach to Factory, Proxy, Singleton, Observer and others. In fact, they're often rendered trivial. The claim that the approaches described in the book apply to any language is just not true. These patterns are for Java and Java-like languages.