Adblock can be used to block flash resources on a server-by-server basis, but Flashblock can block all Flash by content type. If you're the sort of person who can live without Flash entirely, it's a very welcome extension.
They can probably use cookies and web bugs to establish useage patterns that they correlate to machine/browser combinations. While not perfect, it may allow you to make demographic estimates within some acceptible margin of error. You could combine that with other sources of data, such as samples of people that voluntarily answer demographic questions when asked.
How on earth could this no explicitly be a goal, given how obstinate they are about only allowing software licenses that specifically allow for this sort of thing!?
I've read so many 'forking is bad' and 'forking is good' emails. Too few of them admit that it is a double-edged sword. In some respects it is great. In others, not. I'm not sure why that is so difficult to internalize.
Most applications on MacOS X do not require this sudo activity for installation. (Just drag the application bundle into/Applications and run the app using your own privileges.) There are some notable and annoying exceptions to this. For example, the Quicktime and RealPlayer installers are ordinary drag-n-drop with no sudo magic...but the Windows Media player requires sudo authentication. I can't imagine what it needs that Quicktime and RealPlayer do not. Grrr...
Still, your point is taken.
That's a rather optimistic viewpoint. It's entirely possible for someone to do nothing illegal and still find themselves at the blunt end of a civil suit.
I tend to assume that cluefulness shows up in your output, regardless of what your role is.
Re:Requirements?
on
QA != Testing
·
· Score: 2, Interesting
I haven't read the book, but someone at work used to have a copy on their desk, and it used to annoy me. The environment here is that the only clueful people are those who are writing the code, and this manifests itself as a broken QA environment, starting from totally broken functional specs. This had the side effect of putting a lot of decision making power into the hands of the programmers, which the owner of this book did not like. In my circles this book was jokingly called The Cooks Are Running the Kitchen. I hope the content of the book isn't as offensive as the title.
I think your response is deliberately obtuse. The core question doesn't have anything to do with displays being inherently bitmap-oriented. The question is whether the display server and the client are speaking to each other at an efficient level of abstraction...that the display server ultimately ends up rendering to bitmap is a mere implementation detail that has nothing to do with the design of the API and protocol.
The videos are very nice. I'd love to see X11 modernized in this way (so long as the right abstractions are put into the right layers). My favorite part about this story, though, is how Rasterman's post jaws on about how all of this stuff is already done...that sentiment juxtaposed against the first video is hilarious:
About --> Enlightenment...
...and a dialog box pops up that says "version 0.16.999.001". I've never used E, so maybe the version number isn't funny in Rasterman's world...but it's funny in mine.
I'd much rather have a handful of incompetent editors in the world than a million screaming consumers that don't have the backbone to stop consuming the products they hate.
Not only that, but the open content license also allows Google to profit from providing premium access (read: low-latency) to their own instance of the content.
This sort of scenario was anticipated from the beginning when the content license was discussed, and it was considered to be an indicator of success.
While everybody else is discussing the subtle distinction between blackmail and extortion, now might be a good time to revisit the idea of whether projects like Mono really ought to feel comfortable about Microsoft's stance on patents. Any astroturfing mono fanboys care to comment about how benevolent Microsoft is? Why would they extort like this if they didn't want the leverage?
I'm looking at this and thinking some of the same things (specifically, if we have these SPEs what do we need the Altivec unit for?
But then I thought about all of that cool Core/Image/CoreVideo stuff that was demonstrated in a Stevnote about a year ago, where there were all of these fancy realtime imaging and video filters that had a very interesting implementation: the filtert source code is fed into a special compiler that offloads the filter (or chain of filters) onto the GPU of your video card. I'm tempted to think that all of that work of using the GPU in this way was just laying the groundwork for this anticipated CPU. In the very least, one would think that this processor could take the place of that aspect of the GPU, and then the video subsystem potentially gets a lot simpler (just add framebuffer) which could open the door for squeezing more into small form-factor machines.
I find it incredible that Apple could have a patent on generating code from a user drawing a line between two mapped interfaces - doesn't Visio (among many other flowcharters) do it like that?
I don't know about the patent in question, but I do know that the development environment does not generate code like you are suggesting. Instead it created live object instances and serialized them to a file, where the program would unmarshall them during initialization. This was quite innovative back in the day when the best the competitors could muster was code generation. Even today people think of it as code generation...see?:-)
In addition to this, you also have to consider the cost of any data/documents being locked into a file format that is proprietary to a vendor that will deprecate that format when it is convenient for them to do so. I'm not sure how you put a dollar figure on that.
I respectfully disagree. A high-performance rendering library depends heavily on being able to reason out the computational cost of operations. If these operations are open-ended expressions in the PS language, that cost cannot be known by the engine. If the operations are just the low-level primitives provided by the PS/PDF imaging model, then the cost can be known. This has everything to do with eliminating the unknown imposed by the use of the PS language.
The tacit industry standard for this sort of thing seems to be that the date implied by a half or quarter is the last day in that period of time. In this context, "q2 2005" is just a rephasing of "first half of 2005", because they imply the same date. Moreover, that date would probably be the end of June...so you're right it would probably mean sometime this summer.
Slashdot Mirror
Adblock can be used to block flash resources on a server-by-server basis, but Flashblock can block all Flash by content type. If you're the sort of person who can live without Flash entirely, it's a very welcome extension.
They can probably use cookies and web bugs to establish useage patterns that they correlate to machine/browser combinations. While not perfect, it may allow you to make demographic estimates within some acceptible margin of error. You could combine that with other sources of data, such as samples of people that voluntarily answer demographic questions when asked.
So not true. I have the pleasure of using both Debian and MacOS X -- both at work and at home. I wouldn't have it any other way.
Forget 3D, folks. The most remarkable bit of news here is how the bits will go from being "stored" to "living". Holy cow!
How on earth could this no explicitly be a goal, given how obstinate they are about only allowing software licenses that specifically allow for this sort of thing!?
I think we need a "refreshingly direct" mod option that would +1 truthful flamebait.
Gee, this mono thing looks really swell. I was hoping a bajillion astroturfers could post about how groovtacular it is.
Yours truly,
j random shill
P.S. (Something is wrong with the of these threads. I've met more actual people who have tried and loved GNUstep in real life than Mono.)
I've read so many 'forking is bad' and 'forking is good' emails. Too few of them admit that it is a double-edged sword. In some respects it is great. In others, not. I'm not sure why that is so difficult to internalize.
Most applications on MacOS X do not require this sudo activity for installation. (Just drag the application bundle into /Applications and run the app using your own privileges.) There are some notable and annoying exceptions to this. For example, the Quicktime and RealPlayer installers are ordinary drag-n-drop with no sudo magic...but the Windows Media player requires sudo authentication. I can't imagine what it needs that Quicktime and RealPlayer do not. Grrr...
Still, your point is taken.
That's a rather optimistic viewpoint. It's entirely possible for someone to do nothing illegal and still find themselves at the blunt end of a civil suit.
I tend to assume that cluefulness shows up in your output, regardless of what your role is.
I haven't read the book, but someone at work used to have a copy on their desk, and it used to annoy me. The environment here is that the only clueful people are those who are writing the code, and this manifests itself as a broken QA environment, starting from totally broken functional specs. This had the side effect of putting a lot of decision making power into the hands of the programmers, which the owner of this book did not like. In my circles this book was jokingly called The Cooks Are Running the Kitchen. I hope the content of the book isn't as offensive as the title.
I think your response is deliberately obtuse. The core question doesn't have anything to do with displays being inherently bitmap-oriented. The question is whether the display server and the client are speaking to each other at an efficient level of abstraction...that the display server ultimately ends up rendering to bitmap is a mere implementation detail that has nothing to do with the design of the API and protocol.
About --> Enlightenment...
...and a dialog box pops up that says "version 0.16.999.001". I've never used E, so maybe the version number isn't funny in Rasterman's world...but it's funny in mine.
I'd much rather have a handful of incompetent editors in the world than a million screaming consumers that don't have the backbone to stop consuming the products they hate.
Example: "Java!? Icky, bloated runtime. Yuck."
Contrast: "Mono!? It's teh roX0rs! Finally EXE's and DLL's on my Debian box!!!"
Not only that, but the open content license also allows Google to profit from providing premium access (read: low-latency) to their own instance of the content. This sort of scenario was anticipated from the beginning when the content license was discussed, and it was considered to be an indicator of success.
While everybody else is discussing the subtle distinction between blackmail and extortion, now might be a good time to revisit the idea of whether projects like Mono really ought to feel comfortable about Microsoft's stance on patents. Any astroturfing mono fanboys care to comment about how benevolent Microsoft is? Why would they extort like this if they didn't want the leverage?
But then I thought about all of that cool Core/Image/CoreVideo stuff that was demonstrated in a Stevnote about a year ago, where there were all of these fancy realtime imaging and video filters that had a very interesting implementation: the filtert source code is fed into a special compiler that offloads the filter (or chain of filters) onto the GPU of your video card. I'm tempted to think that all of that work of using the GPU in this way was just laying the groundwork for this anticipated CPU. In the very least, one would think that this processor could take the place of that aspect of the GPU, and then the video subsystem potentially gets a lot simpler (just add framebuffer) which could open the door for squeezing more into small form-factor machines.
Excuse, me, I'm having a bit of a koolaid rush.
I don't know about the patent in question, but I do know that the development environment does not generate code like you are suggesting. Instead it created live object instances and serialized them to a file, where the program would unmarshall them during initialization. This was quite innovative back in the day when the best the competitors could muster was code generation. Even today people think of it as code generation...see? :-)
In addition to this, you also have to consider the cost of any data/documents being locked into a file format that is proprietary to a vendor that will deprecate that format when it is convenient for them to do so. I'm not sure how you put a dollar figure on that.
I respectfully disagree. A high-performance rendering library depends heavily on being able to reason out the computational cost of operations. If these operations are open-ended expressions in the PS language, that cost cannot be known by the engine. If the operations are just the low-level primitives provided by the PS/PDF imaging model, then the cost can be known. This has everything to do with eliminating the unknown imposed by the use of the PS language.
I think you and I are on the same page, but we're still lacking buy-in from some critical stakeholders.
That's ok, you only have to hold it for a few centons.
The tacit industry standard for this sort of thing seems to be that the date implied by a half or quarter is the last day in that period of time. In this context, "q2 2005" is just a rephasing of "first half of 2005", because they imply the same date. Moreover, that date would probably be the end of June...so you're right it would probably mean sometime this summer.