If you don't give us Hebrew, we'll declare you a monopoly! It was already declared a monopoly. There were no new laws written. It's just that since they refused to do MacOS X Office with proper BiDI (read: Hebrew) support, the citizens actually, *shudder*, had the government enforce the laws.
Hmm, OK, I know this was a joke, but... 2. Macs don't support Hebrews 1) they don't support Hebrew, not Hebrews 2) they do support Hebrew, just that the MacOS X versions of Office don't. In the article they talk about the OS supporting R to L scripts such as Hebrew (and Arabic and Urdu) since 10.2.
Not quite what he asked, there's no "Make persistent cookie to session cookie" option. I'd like this too. I think they didn't put this in because of bloat/complexity issues, but I pretty much wished for what the parent asked for.
Whats with the "redundant" mods? He did take a leave of absence, yet anyone who corrected the post gets modded redundant. Do the mods you think the posters are part of some vast Microsoft/Intel conspiracy to trash Transmeta, so we need to hide where Linux is at? sheesh.
Unix, lets call it "hasuseraclue()" [1].... [1] Note: by reverse engineering the code, we know that above system call return 0 when ran on the system of the author of the previous paper.
I'm kind of pissed at the "heh, he's a moron, he opens attachments" garbage. Aren't we supposed to open attachments? Aren't attachments designed to be used? How many times have you had to warn Linux users "don't click on attachments". Or even Mac users (pre or post Mac OS X). Attachments by themselves aren't all that evil. Holes in both the design and implementation of Outlook/Outlook Express have made it where using a very useful feature of email scares the crap out of you because you're worried about catching something. Thanks to the fact that Windows is on 95% of desktops, flaws in Windows are seen to be flaws in all computers, so people just accept it, and ridicule those who dare think they might be able to use a feature of email for it's intended purose.
In a typical business model, shouldn't the boss not only know his employee's jobs, but be able to do them in most cases!?
Actually, there's a school of thought that says this is actually a pretty bad thing, because there's too much incentive for them to actually try to.
A manager's job is not doing as much as coordinating. You have to get out of the though process of being a resource and start getting in to the role of utilizing resources most efficiently. The most efficient use of your time is to multiply your effort by making the most efficient use of your resources, the people who work for you. An effective manager can't think of himself as a smarter frontline guy, he has to think of himself as someone who gets all the smart frontline guys working for him. Think of the manager as the conductor of a symphony. He doesn't need to play the bassoon, needs to be able to get the best out of the bassoon player.
That being said, it's always good to have a backup, and the manager is allowed to be a very short term backup. If he's becoming a long-term backup, there's a problem, and he needs to fix it.
What if your manager is too smart, or at least thinks he is? They tend to micro-manage. Worst case, they think they're smart but they're not, so they micromanage, much up you getting your stuff done, and don't get their stuff done, so the whol eteam has to pitchin on his work or he overworks and gets cranky and takes it out on the team. None are good situations.
I think the C64 appeal for me is much like Linux' appeal for a lot of people now. For a cheap price ($200 or so, expensive in today's dollars but damn cheap relativ to the PCs of the day) you could get a machine with a programming environment. You got the small programmers guide that showed you a bit of BASIC, and some of the cool memory addresses. A lot of the stuff was in BASIC, with source (compiled BASIC? whats that? =) so you could see what was happening. I liked it so much, I still remember some of the SID programmed songs that came on the demo tape (yeah, I had a Datasette, wasn't cool enough for a floppy drive). Fairly open too; I got a "Mapping the C64" book I finally threw out just a few years ago, years after I got rid of my real C64 (power brick problems, never replaced the transformer).
I think in some ways it's better than Linux, for some odd reasons. Though MS-BASIC is a pretty bad language, it is some language, always there, and I never had pointer problems in it. The editor was horrible (ever have to renumber large amounts of lines in BASIC, **shudder**) but the ease of getting just anything written (even if it was horrible spaghetti code) made it fun. The biggest coolness for me was being able to control ALL of the machine. Mapping the C64 told you what EVERY mem address did. How to reset the display, how to program the SID and the UART ports, everything. Get that, and the Compute! 6502 assembler programming book, and you feel you have total control over the machine; you can use it to it's full potential. Even with a totally OpenSource system now, you can't do that with modern machines. Even if you had a free and open BIOS (which I don't know of any) there are just too many things to know to be able to know everything. How many LOC is the Linux Kernel? I'm sure not even Linus or A. Cox knows all of them. There was real geek seduction in that amnount of access.
Re:Spacing them out may not be so bad
on
Longhorn in 2006
·
· Score: 1
These are nits, and don't change your argument really, but being a geek of course i must comment....
MacOS 7 didn't bring true multitasking, it improved on Multi-Finder (cooperative multitasking), which was a standard part of MacOS System 6. The transition to Sys 7 was (relatively) smooth and felt more evolutionary than it was, mostly because it cleaned up some UI stuff in the finder and most of the major changes were under the hood. Hmm, but then again, it brought the idea of "system enablers", so I guess so much for the "smooth" part.
If your definition of "true" multi-tasking is pre-emptive multi-tasking (because a lockup in an app can't lock up the entire computer) that didn't come into play until MacOS X.
Most of the later changes in MacOS (8 and 9) were cosmetic and in bundled userland apps, not really OS level things. The real cool stuff (OpenDoc) never really worked in the real world. I miss the potential that was OpenDoc. CyberDog, where are you!!!!
According to SoftMaker, all that was involved was a recompile. So it cost them extremely little to support FreeBSD.
To be honest, this statements bugs me. Even if all they did do is recompile, and if it worked (a recompile is not sufficient in all cases, they're pretty lucky) that just solves the coding aspect of the app.
Other major aspects: Packaging. Documentation. Testing.
Of those 3, packaging is sure to be done, since they can't really ship without it being installable. Documentation, well, for the most part they can use the warmed over Linux docs (with maybe some errata on installation and printing) and users should be fine. What I'd be worried about is if they did a full QA run on it. Becaue it works on Linux doesn't mean it's just going to work on FreeBSD, and I hope I'm correct in assuming they did do a QA run, just didn't mention it.
Any time I see AutoRun, I run out and download PowerToys and disable it.
Am I in violation of the DMCA if I'm logged in as a user with no admin rights, therefore without rights to install drivers? Any copy protection scheme that requires a device driver mucking with my CD is stupid and deserves to fail. Any company who's market cap (I mean, didn't they see this in testing?) depends on said system deserves to be devalued.
Doubtful considering it is the poorest country in the world last I checked. That kid would probably be more concerned with where his next meal was coming from rather than being 'bored'.
I don't pretend to know Mozambique enough to say that there are zero people with net access, the inclination, the time, and the skillset to create malicious code. If not, then substitute some other location. Tuvalu may be better; it has some net uinfrastructure and some cash because of the selling of the.tv TLD.
In actuality it doesn't quite matter if it's Mozambique, or Tuvalu, or Russia, or Israel, or anywhere for that matter. It doesn't take a team of people. Slammer killed off the Internet in South Korea and disabled ATMs and some emergency services, and it one damn 376 byte UDP packet. It just takes one individual with the the time and will and connection to do it, and it may come from anywhere.
When I was taking my digital circuits class (basicially creating stuff with discrete logic gates; NAND, XOR, stuff like that) we were introduced to the concept of Don't Care states. Basically, there were certain states of the input that we assumed would never happen, and we could cluster the known states to be more efficient as far as the number of gates. The problem was, what happened if by some reason, we did end up in a bad, assumed it would never happen but here we are state? Unsure, you kind of hope that you eventually get pushed to a valid state. You hope, but you might get some new automata that will switch from the one unexpected state to the next. We then had an assignment to push those illegitimate states back to a valid state in your state machine.
Buffer overflows and stack smashes (though not all errors) are these "assume we know the states going in, but look here we are" states. But I don't think we can use the solution from the above example. The "push all bad states back to the wanted automata" was an example with a small number of states. You can't really do this with a general computer program; you get a large number of states so it's difficult to account for all possible bad states, and the code to push the bad states to a valid state is going to be about as large as the original code with all the same possible bugs.
But there are techniques you can do to help the state stuff. ElectricFence does some more manipulation of the MMU to prevent overwrites. Though used as a debugging tool, it may be useful as a security tool. ProPolice and StackGuard help stop the "new automata". OpenBSD now has W^X protection on architectures that support it. Since you now can't put shell code on the stack, you now need to find it in libraries, and OpenBSD helps there too by randomizing the locations of loaded shared libraries so you can't say, find the code for system() all that easily.
But there still is weird stuff for a system that can be assumed to be under constant attack. Why is the return value for functions on the stack where it is vulnerable to be overwritten? Systems aren't designed for security, and it goes all the way to the chip level. Palladium, or whatever they're calling it these days won't help. It only ensures that code that's initially loaded by the OS is from a known source. It doesn't prevent the unwanted states. I'm sure the RPC code that caused Blaster would have been signed under Palladium.
This is mostly me talking out of my ass. I never really formally studied any of these topics, just some stream of consciousness stuff that I thought of last time our workplace went down from Blaster.
I was at lunch recently with a friend who happens to work with me. We talked about the Von Neumann programming model. Any code that runs on a current processor ends up being put into a finite state Von Neumann machine. Machines have gotten so complex now, with so many services exposed, that though it's in theory still a finite deterministic state machine, it's essentially become an infinite state machine. There are too many places for things to interact, too many places for "gee, I never thought of that". Some of these are marketing related - "so how about we have IE and Visual Basic integrated into Outlook. That will be a cool feature we can sell, and there's no way that can bite us in the ass...", some are people who fit categories 1, 2, and 3.
Language does matter, but insomuch only as a filter. A lot damage I've seen comes from Outlook running VBS. Language choice reduces some (possibly many) of the states. But it is only a filter; at some point code has to meet silicon. C/C++ gets the worst reviews because it does the least amount of filtering. Hell, not being a filter is C's core design principle. In an old non-memory protected OS (DOS, Win16, MacOS = 9) you could essentially hit anywhere that wasn't kernel memory. Modern OSes reduce the possible states somewhat by protected memory spaces; you can't trash anyone elses code because you're in your own VM space. It also reduces some damage by shutting down the app if it knows of a bad access (out of program space) but it can't eliminate all because it only has a very course idea of the app going to an unintended state (e.g. SIGSEGV, SIGBUS, SIGFPE...).
Other languages are more effective filters, because they were written with that in mind. Java is a much more effective filter, eliminating many states, but not all error states. Java can't prevent you from having all your code being world writeable.
I guess one thing I'm asking is what research is there in non-Von Neumann architectures? And since we're probably not going to a post Von Neumann world any time soon, what lessons can we take from these to help secure our machines? In a more and more connected world where my fridge will eventually tell me when I'm out of milk, what can we do?
I also think tools suck. We still live in a C and C++ dominated source world. And while the tools to help reduce that complexity and unintended states have barely advanced (how many people think machine aided code analysis means to add -W -Wall to their compiles) the complexity (think how many more lines of code are in by default in your basic Qt app vs. hello world; how many more lines of code in your OS?) and threat (EVERYTHING is connected to the Internet, everything is under 24/7 threat from some bored kid in Mozambique). Where are the tools? Why doesn't splint do C++ code? Everyone and their mom has a combo IRC client/Text editor, but some of our basic infrastructure tools are aging very ungracefully.
Jokes aside (and you stole mine, I was going to write my own version of it:
Great oxymorons:
Jumbo shrimp
Millitary intelligencse
BASIC
Utah Jazz
Writing Secure Code from Microsoft
BASIC gets a nod because it's the only single word good oxymoron I know
Anyways, Microsoft hires some very talented guys. A lot of their problems are marketing related. "Hey, we need to ship, I don't care how much QA you've used". Or even worse "we need to get the whole world integrated, everything shares code with everything, hey lets have our email system atomatically run scripts, because no one in an office would send malicious code inhouse, right?" and thereby grow the torrent of worms. MS is a big enough company that it can be solid in theory but fall well short in practice.
I'm at 4.9 PRE as well. Is there a way to track 4.8, but get enhancements as well as security changes, but not move to 4.9 until its actually released?
"If I have seen further [than you and Descartes] it is by standing upon the shoulders of giants."
-- Sir Isaac Newton (1642-1727) from Letter to Robert Hooke, Feb. 5, 1675/76.
The web, as first envisioned by Tim Berners Lee, was simply a way of passing around physics papers, a more efficient way of disseminating knowledge.
any article, its been in any computer forum. I've see it in linux ones when talking about the new 2.6 features, and in pretty much macos story as well
So is this a deal to bring back Scully?
=)
If you don't give us Hebrew, we'll declare you a monopoly!
It was already declared a monopoly. There were no new laws written. It's just that since they refused to do MacOS X Office with proper BiDI (read: Hebrew) support, the citizens actually, *shudder*, had the government enforce the laws.
Hmm, OK, I know this was a joke, but...
2. Macs don't support Hebrews
1) they don't support Hebrew, not Hebrews
2) they do support Hebrew, just that the MacOS X versions of Office don't. In the article they talk about the OS supporting R to L scripts such as Hebrew (and Arabic and Urdu) since 10.2.
Maybe this is proof G-d uses OpenOffice? =)
Not quite what he asked, there's no "Make persistent cookie to session cookie" option. I'd like this too. I think they didn't put this in because of bloat/complexity issues, but I pretty much wished for what the parent asked for.
Whats with the "redundant" mods? He did take a leave of absence, yet anyone who corrected the post gets modded redundant. Do the mods you think the posters are part of some vast Microsoft/Intel conspiracy to trash Transmeta, so we need to hide where Linux is at? sheesh.
Unix, lets call it "hasuseraclue()" [1]. ...
[1] Note: by reverse engineering the code, we know that above system call return 0 when ran on the system of the author of the previous paper.
Shouldn't it return -1 and set errno to EDOOFUS
To use this yet again...
They looked deep inside my soul and assigned me a number based on the order in which I joined.
- Homer Simpson, new Stonecutter.
I'm kind of pissed at the "heh, he's a moron, he opens attachments" garbage. Aren't we supposed to open attachments? Aren't attachments designed to be used? How many times have you had to warn Linux users "don't click on attachments". Or even Mac users (pre or post Mac OS X). Attachments by themselves aren't all that evil. Holes in both the design and implementation of Outlook/Outlook Express have made it where using a very useful feature of email scares the crap out of you because you're worried about catching something. Thanks to the fact that Windows is on 95% of desktops, flaws in Windows are seen to be flaws in all computers, so people just accept it, and ridicule those who dare think they might be able to use a feature of email for it's intended purose.
In a typical business model, shouldn't the boss not only know his employee's jobs, but be able to do them in most cases!?
Actually, there's a school of thought that says this is actually a pretty bad thing, because there's too much incentive for them to actually try to.
A manager's job is not doing as much as coordinating. You have to get out of the though process of being a resource and start getting in to the role of utilizing resources most efficiently. The most efficient use of your time is to multiply your effort by making the most efficient use of your resources, the people who work for you. An effective manager can't think of himself as a smarter frontline guy, he has to think of himself as someone who gets all the smart frontline guys working for him. Think of the manager as the conductor of a symphony. He doesn't need to play the bassoon, needs to be able to get the best out of the bassoon player.
That being said, it's always good to have a backup, and the manager is allowed to be a very short term backup. If he's becoming a long-term backup, there's a problem, and he needs to fix it.
What if your manager is too smart, or at least thinks he is? They tend to micro-manage. Worst case, they think they're smart but they're not, so they micromanage, much up you getting your stuff done, and don't get their stuff done, so the whol eteam has to pitchin on his work or he overworks and gets cranky and takes it out on the team. None are good situations.
I think the C64 appeal for me is much like Linux' appeal for a lot of people now. For a cheap price ($200 or so, expensive in today's dollars but damn cheap relativ to the PCs of the day) you could get a machine with a programming environment. You got the small programmers guide that showed you a bit of BASIC, and some of the cool memory addresses. A lot of the stuff was in BASIC, with source (compiled BASIC? whats that? =) so you could see what was happening. I liked it so much, I still remember some of the SID programmed songs that came on the demo tape (yeah, I had a Datasette, wasn't cool enough for a floppy drive). Fairly open too; I got a "Mapping the C64" book I finally threw out just a few years ago, years after I got rid of my real C64 (power brick problems, never replaced the transformer).
I think in some ways it's better than Linux, for some odd reasons. Though MS-BASIC is a pretty bad language, it is some language, always there, and I never had pointer problems in it. The editor was horrible (ever have to renumber large amounts of lines in BASIC, **shudder**) but the ease of getting just anything written (even if it was horrible spaghetti code) made it fun. The biggest coolness for me was being able to control ALL of the machine. Mapping the C64 told you what EVERY mem address did. How to reset the display, how to program the SID and the UART ports, everything. Get that, and the Compute! 6502 assembler programming book, and you feel you have total control over the machine; you can use it to it's full potential. Even with a totally OpenSource system now, you can't do that with modern machines. Even if you had a free and open BIOS (which I don't know of any) there are just too many things to know to be able to know everything. How many LOC is the Linux Kernel? I'm sure not even Linus or A. Cox knows all of them. There was real geek seduction in that amnount of access.
I for one will welcome our kung fu stickman overlords
yes, I am totally trolled out...
These are nits, and don't change your argument really, but being a geek of course i must comment....
MacOS 7 didn't bring true multitasking, it improved on Multi-Finder (cooperative multitasking), which was a standard part of MacOS System 6. The transition to Sys 7 was (relatively) smooth and felt more evolutionary than it was, mostly because it cleaned up some UI stuff in the finder and most of the major changes were under the hood. Hmm, but then again, it brought the idea of "system enablers", so I guess so much for the "smooth" part.
If your definition of "true" multi-tasking is pre-emptive multi-tasking (because a lockup in an app can't lock up the entire computer) that didn't come into play until MacOS X.
Most of the later changes in MacOS (8 and 9) were cosmetic and in bundled userland apps, not really OS level things. The real cool stuff (OpenDoc) never really worked in the real world. I miss the potential that was OpenDoc. CyberDog, where are you!!!!
According to SoftMaker, all that was involved was a recompile. So it cost them extremely little to support FreeBSD.
To be honest, this statements bugs me. Even if all they did do is recompile, and if it worked (a recompile is not sufficient in all cases, they're pretty lucky) that just solves the coding aspect of the app.
Other major aspects:
Packaging.
Documentation.
Testing.
Of those 3, packaging is sure to be done, since they can't really ship without it being installable. Documentation, well, for the most part they can use the warmed over Linux docs (with maybe some errata on installation and printing) and users should be fine. What I'd be worried about is if they did a full QA run on it. Becaue it works on Linux doesn't mean it's just going to work on FreeBSD, and I hope I'm correct in assuming they did do a QA run, just didn't mention it.
Any time I see AutoRun, I run out and download PowerToys and disable it.
Am I in violation of the DMCA if I'm logged in as a user with no admin rights, therefore without rights to install drivers? Any copy protection scheme that requires a device driver mucking with my CD is stupid and deserves to fail. Any company who's market cap (I mean, didn't they see this in testing?) depends on said system deserves to be devalued.
Doubtful considering it is the poorest country in the world last I checked. That kid would probably be more concerned with where his next meal was coming from rather than being 'bored'.
.tv TLD.
I don't pretend to know Mozambique enough to say that there are zero people with net access, the inclination, the time, and the skillset to create malicious code. If not, then substitute some other location. Tuvalu may be better; it has some net uinfrastructure and some cash because of the selling of the
In actuality it doesn't quite matter if it's Mozambique, or Tuvalu, or Russia, or Israel, or anywhere for that matter. It doesn't take a team of people. Slammer killed off the Internet in South Korea and disabled ATMs and some emergency services, and it one damn 376 byte UDP packet. It just takes one individual with the the time and will and connection to do it, and it may come from anywhere.
When I was taking my digital circuits class (basicially creating stuff with discrete logic gates; NAND, XOR, stuff like that) we were introduced to the concept of Don't Care states. Basically, there were certain states of the input that we assumed would never happen, and we could cluster the known states to be more efficient as far as the number of gates. The problem was, what happened if by some reason, we did end up in a bad, assumed it would never happen but here we are state? Unsure, you kind of hope that you eventually get pushed to a valid state. You hope, but you might get some new automata that will switch from the one unexpected state to the next. We then had an assignment to push those illegitimate states back to a valid state in your state machine.
Buffer overflows and stack smashes (though not all errors) are these "assume we know the states going in, but look here we are" states. But I don't think we can use the solution from the above example. The "push all bad states back to the wanted automata" was an example with a small number of states. You can't really do this with a general computer program; you get a large number of states so it's difficult to account for all possible bad states, and the code to push the bad states to a valid state is going to be about as large as the original code with all the same possible bugs.
But there are techniques you can do to help the state stuff. ElectricFence does some more manipulation of the MMU to prevent overwrites. Though used as a debugging tool, it may be useful as a security tool. ProPolice and StackGuard help stop the "new automata". OpenBSD now has W^X protection on architectures that support it. Since you now can't put shell code on the stack, you now need to find it in libraries, and OpenBSD helps there too by randomizing the locations of loaded shared libraries so you can't say, find the code for system() all that easily.
But there still is weird stuff for a system that can be assumed to be under constant attack. Why is the return value for functions on the stack where it is vulnerable to be overwritten? Systems aren't designed for security, and it goes all the way to the chip level. Palladium, or whatever they're calling it these days won't help. It only ensures that code that's initially loaded by the OS is from a known source. It doesn't prevent the unwanted states. I'm sure the RPC code that caused Blaster would have been signed under Palladium.
Wow, this dork trolls Linux stuff too? I thought he just trolled BSD. I guess there is a new spirit of Linux/FreeBSD cooperation afterall!
This is mostly me talking out of my ass. I never really formally studied any of these topics, just some stream of consciousness stuff that I thought of last time our workplace went down from Blaster.
...).
I was at lunch recently with a friend who happens to work with me. We talked about the Von Neumann programming model. Any code that runs on a current processor ends up being put into a finite state Von Neumann machine. Machines have gotten so complex now, with so many services exposed, that though it's in theory still a finite deterministic state machine, it's essentially become an infinite state machine. There are too many places for things to interact, too many places for "gee, I never thought of that". Some of these are marketing related - "so how about we have IE and Visual Basic integrated into Outlook. That will be a cool feature we can sell, and there's no way that can bite us in the ass...", some are people who fit categories 1, 2, and 3.
Language does matter, but insomuch only as a filter. A lot damage I've seen comes from Outlook running VBS. Language choice reduces some (possibly many) of the states. But it is only a filter; at some point code has to meet silicon. C/C++ gets the worst reviews because it does the least amount of filtering. Hell, not being a filter is C's core design principle. In an old non-memory protected OS (DOS, Win16, MacOS = 9) you could essentially hit anywhere that wasn't kernel memory. Modern OSes reduce the possible states somewhat by protected memory spaces; you can't trash anyone elses code because you're in your own VM space. It also reduces some damage by shutting down the app if it knows of a bad access (out of program space) but it can't eliminate all because it only has a very course idea of the app going to an unintended state (e.g. SIGSEGV, SIGBUS, SIGFPE
Other languages are more effective filters, because they were written with that in mind. Java is a much more effective filter, eliminating many states, but not all error states. Java can't prevent you from having all your code being world writeable.
I guess one thing I'm asking is what research is there in non-Von Neumann architectures? And since we're probably not going to a post Von Neumann world any time soon, what lessons can we take from these to help secure our machines? In a more and more connected world where my fridge will eventually tell me when I'm out of milk, what can we do?
I also think tools suck. We still live in a C and C++ dominated source world. And while the tools to help reduce that complexity and unintended states have barely advanced (how many people think machine aided code analysis means to add -W -Wall to their compiles) the complexity (think how many more lines of code are in by default in your basic Qt app vs. hello world; how many more lines of code in your OS?) and threat (EVERYTHING is connected to the Internet, everything is under 24/7 threat from some bored kid in Mozambique). Where are the tools? Why doesn't splint do C++ code? Everyone and their mom has a combo IRC client/Text editor, but some of our basic infrastructure tools are aging very ungracefully.
Hmm, rant mode off. =)
Great oxymorons:
BASIC gets a nod because it's the only single word good oxymoron I know
Anyways, Microsoft hires some very talented guys. A lot of their problems are marketing related. "Hey, we need to ship, I don't care how much QA you've used". Or even worse "we need to get the whole world integrated, everything shares code with everything, hey lets have our email system atomatically run scripts, because no one in an office would send malicious code inhouse, right?" and thereby grow the torrent of worms. MS is a big enough company that it can be solid in theory but fall well short in practice.
I don't know whats funnier, this post, or the people who didn't get it and modded down.
Thanks, lots of info. Does RELENG_4_8 get any updates besides security fixes?
I'm not really worried about uname as much as stability. Not sure how 4.9-PRE compares in stability to tracking RELENG_4_8.
I'm at 4.9 PRE as well. Is there a way to track 4.8, but get enhancements as well as security changes, but not move to 4.9 until its actually released?
"If I have seen further [than you and Descartes] it is by standing upon the shoulders of giants."
-- Sir Isaac Newton (1642-1727) from Letter to Robert Hooke, Feb. 5, 1675/76.
The web, as first envisioned by Tim Berners Lee, was simply a way of passing around physics papers, a more efficient way of disseminating knowledge.
A lot of Kai's stuff (Photoshop plugins) are pretty bad. Different for sake of different.
Oh, okay. How do you want me to do that? Use smoke signals over TCP/IP?
No, H20-IP