.NET Framework - Longsword +4 of Sucking Less
on
.NETly News
·
· Score: 1
Anybody who felt the excruciating pain of programming the Win32 API will see the.NET Framework as the salvation (provided they can't wriggle their way into programming Perl/PHP/Java/GNOME/KDE/any other language or API that was actually/designed/ rather than just grown - the way cancers get grown).
Also,.NET might have some trully positive effects - namely, it seems that it might enable functional languages to actually enter the mainstream.
Either way, personally I'll just wait and see. A couple of years from now, my opinion of MS will strongly depend on whether there'll be more than one Passport authority and whether you'll be able to talk to them from Mono.
I'm actually developing medical imaging and telemedicine software and, well, I hear ya!
... except that for the volumetric rendering, GF4 is/still/ not powerful enough. You need 256 megs to store the dataset, believe it or not.
BTW, requirements for a medical imaging app are simply insane. For example, all the image processing has to be done in realtime during image acquisition (because the guy who has a tube going from his mouth to his stomach and a couple of needles in his arms isn't going to be very understanding when you tell him that the computer is currently processing data from the previous patient...)
The problem with methanol is that it's highly poisonous. This means that it can't be cheap to produce (because you need extra safety measures in the factory) and it can't be cheap to distribute (your tamperproof containers must be *really* tamperproof).
Or you can switch to cheap, mass-produced methanol dispensers that occasionally kill their users.
IMHO, it's a good idea to wait for hydrogen fuel cells. First, hydrogen is environmentally safe, and can be stored in such a way that it won't be flammable nor explosive (at least not more so than alchohol is). Second, you can produce it from water, meaning it's probably practical to build a rechargable hydrogen cell. You'd recharge it from the wall socket and a glass of water.
I'm just stating the current situation. Under the current laws, the media companies are protected.
A media company that bases its business model on ignoring the power that's given to it will have a Problem. Unless, of course, the copyrights become trully unenforcable.:)
> Because I've yet to see a sucessful media producing revenue model that doesn't at some stage rely on copyright protection.
Remember that 'less protection' is not the same as 'no protection'.
Also, the media companies are protected, period. They can't choose not to rely on the protection, since they have to compete for the investors with the overprotected monopolists.
Wherever they picked their terminology from, it's *not* from coding theory articles, or topology articles, or probability theory, or any other branch of Math I've ran into. (IAAM - I Am A Mathematician).
Whoever wrote that text has never read any of these articles. And is not a mathematician. Nor a programmer.
Draw your own conclusions about the company.
--
Re:Genetically modified food has existed for ages
on
Monsanto and PCBs
·
· Score: 2, Insightful
The problem is not in the genetic modification as such. It's more a matter of what gets grafted into the plants. When you add a banana gene into corn, that's a bit of a problem if you're allergic to bananas (and some people in fact are), especially if you eat corn without knowing that the gene is there.
There are two actual problems with GM food. The first is allergies. GM food contain new genes that we haven't encountered before, and it turned out in practice that quite a few of these are seriously allergenic for many people. The other, more serious problem is that GM plants are so often produced to make them more resistent to pesticides. Thing is, some of these pesticides persist, and well, humans are/not/ GMed for resistency.
> Which is bull, because all these languages, even assembler, are computationally equivalent (Turing complete). It is just more work and uglier to achieve.
No, the original poster is quite right. Code generation and evaluation means that a LISP program can parse and rewrite itself. The 'rewrite' part is possible but ugly as hell in C (dump the source, exec the compiler, dl_open... you get the idea?). LISP macrosystem and Scheme syntax transformer allow you to modify the/compiler/ in a Turing-complete way. (and no, #defines are not Turing complete, nor they can parse their arguments).
The necessary support for this is in the XFree86 CVS already. There is a screenshot (check the Hello World! window) and the source code for this. Don't worry, Keith Packard has thought of everything.;)
There's also SART, the renderer I'm working on. Its current focus is rendering, but there'll be a modeller in a, well, not too near future. Unfortunately I don't have the time to work on it as much as I'd like.
Current features are full programability (using guile), support for NURBS, blobs, parametric and implicit surfaces, volume rendering (including nonuniform textured volumes), radiosity, postprocessing. Check http://petra.zesoi.fer.hr/~silovic/sart for more info.
In fact you -can- inherit from any gtk+ class. While C, in itself, is not object oriented, gtk+ is - it's an OO system built on top of C. The main difference is that it exists on semantic level, rather than syntactic.
It supports inheritance, encapsulation, messaging, signals, exportable properties, and dynamic class identification.
Actually they are solvable in the sense that 'solution exists', not in the sense 'we can find the solution'. This is a distinction that was a topic of a rather sharp flamewar in the math community around 100 years ago. IIRC it was Hilbert who gave the first proof that was purely existential (i.e. it proved that something existed without a slightest hint as to how it might be found - the problem was one in algebraic geometry).
Actually there is an answer to that: Open Source. A small gaming company can safeguard against being clobbered and at the same time ensure external development help by going OSS from *early* stages (rather than OSSing old titles that aren't profitable any longer), and then make money by charging for gameserver access and selling packaged games (i.e. things that are added to the sources themselves: scenarios, graphics, etc).
I'm talking from the experience - there will be an announcement soonish (can't go into details right now - wouldn't do for our website to get slashdotted before there is anything to download:) ).
> 1.For a project on the scale of Mozilla, can we realistically expect non-core developers to be useful in "early" stages?
The problem, IMHO, is not so much the size itself... it's rather modularity of the system. Most OSS project are either small-scale or have been designed from the beginning to be very modular, with *very* small module scale and limited module interaction. This means plugin/component architecture from the very start, and constrained interface complexity (i.e. it's predecided that components use VERY simple protocols to talk to each other).
Mozilla, currently, seems to have moved in this direction - it uses XPCOM and has IDL interfaces to all its internals. Unfortunately, it wasn't this way all the time, and the original monolythic Netscape sources were not merely daunting, as Mozilla's are, but nearly unworkable for the outsiders.
After the rewrite of the entire system, things cleared up a lot - Mozilla's internals are pretty close to Mnemonic's (the OSS browser designed for modularity). Unfortunately at this point (early 1999) the browser fell long behind schedule and so rumors of its early demise became prominent. Lately, however, there's been a noticable influx of the external developers to the effort - precisely because it's beginning to look managable.
Diffie-Hellman is not equivalent to RSA. It's vulnerable to man-in-the-middle attack. There are, however, some free assymetric algorithms that *can* be used - elliptic curves, for instance.
But the real problem is that many data-exchange standards (SSL, and MP3) *require* you to use patented technology. This is bad - you can't even save your data without violating a patent.
> For the Linux community outside of China, on the other hand, this could be bad. In the United States and in much of the rest of the world, we still fear the "red bastards" and every thing even slightly smelling of communism is seen as taboo and evil. Linux as an OS may be tainted by communism.
Thing is... There are about billion people in China. And apart from piracy (not that they're too squemish about piracy, mind you - but then the only countries who really care about piracy are US and Western Europe, IMHO) they can't afford any other OS anyway. Say, 1% actually get an access to computer and one in thousand of these contribute to development. That's 10,000 developers - I wouldn't call it bad.
This reminds me of kernel-2.2. Sure, it took two years. Was it worth the wait? Definitely.
Mozilla is *not* going to be shipped before it's ready. I've played with the latest releases, and I can only say I'm impressed by what it does (hint: incremental table rendering - you can read Slashdot page with 200 comments in a second that it takes to fetch the first comment, while it proceeds to read the rest of them). In fact, surfing the web with Mozilla is as exhillerating as it used to be with Netscape-1.0 after Mosaic.
So, I for one prefer to wait for a browser that is a killer than to get almost-Netscape-but-not-quite-there rushed hack.
---
Re:X *is* a media-savvy, compositing GUI!
on
Is X The Future?
·
· Score: 1
> But it is very likely that Berlin will have an X compatibility layer (it won't get any widespread adoption otherwise). Then, GTK/QT will work, and so will all the apps, then you can start porting GTK/QT to Berlin if you want, and there ya go, a group of developers don't ever notice the transition.
Meaning you get even slower and more bloated double-windowed system. At least extending X means you do things/once/.
Not that it's really needed. X has builtin image processing. Ever heard of Xie? No, not the X Input Extension, there is another one called X Image Extension. Unfortunately the only person I talked with who/heard/ about it was Rasterman and he told me he couldn't grasp its API. Neither could I.
The point being, why bother? X has it all. XFree86 doesn't support antialiesed font rendering, however, that has been worked on (I read somewhere that the code is currently commented out because they lack developers). And also, don't whine. If you don't like X, help XFree people to make it into what you like.
Slashdot Mirror
Anybody who felt the excruciating pain of programming the Win32 API will see the .NET Framework as the salvation (provided they can't wriggle their way into programming Perl/PHP/Java/GNOME/KDE/any other language or API that was actually /designed/ rather than just grown - the way cancers get grown).
.NET might have some trully positive effects - namely, it seems that it might enable functional languages to actually enter the mainstream.
Also,
Either way, personally I'll just wait and see. A couple of years from now, my opinion of MS will strongly depend on whether there'll be more than one Passport authority and whether you'll be able to talk to them from Mono.
---
I'm actually developing medical imaging and telemedicine software and, well, I hear ya!
/still/ not powerful enough. You need 256 megs to store the dataset, believe it or not.
... except that for the volumetric rendering, GF4 is
BTW, requirements for a medical imaging app are simply insane. For example, all the image processing has to be done in realtime during image acquisition (because the guy who has a tube going from his mouth to his stomach and a couple of needles in his arms isn't going to be very understanding when you tell him that the computer is currently processing data from the previous patient...)
---
The problem with methanol is that it's highly poisonous. This means that it can't be cheap to produce (because you need extra safety measures in the factory) and it can't be cheap to distribute (your tamperproof containers must be *really* tamperproof).
Or you can switch to cheap, mass-produced methanol dispensers that occasionally kill their users.
IMHO, it's a good idea to wait for hydrogen fuel cells. First, hydrogen is environmentally safe, and can be stored in such a way that it won't be flammable nor explosive (at least not more so than alchohol is). Second, you can produce it from water, meaning it's probably practical to build a rechargable hydrogen cell. You'd recharge it from the wall socket and a glass of water.
--
I'm just stating the current situation. Under the current laws, the media companies are protected.
:)
A media company that bases its business model on ignoring the power that's given to it will have a Problem. Unless, of course, the copyrights become trully unenforcable.
--
> Because I've yet to see a sucessful media producing revenue model that doesn't at some stage rely on copyright protection.
Remember that 'less protection' is not the same as 'no protection'.
Also, the media companies are protected, period. They can't choose not to rely on the protection, since they have to compete for the investors with the overprotected monopolists.
--
Wherever they picked their terminology from, it's *not* from coding theory articles, or topology articles, or probability theory, or any other branch of Math I've ran into. (IAAM - I Am A Mathematician).
Whoever wrote that text has never read any of these articles. And is not a mathematician. Nor a programmer.
Draw your own conclusions about the company.
--
The problem is not in the genetic modification as such. It's more a matter of what gets grafted into the plants. When you add a banana gene into corn, that's a bit of a problem if you're allergic to bananas (and some people in fact are), especially if you eat corn without knowing that the gene is there.
/not/ GMed for resistency.
There are two actual problems with GM food. The first is allergies. GM food contain new genes that we haven't encountered before, and it turned out in practice that quite a few of these are seriously allergenic for many people. The other, more serious problem is that GM plants are so often produced to make them more resistent to pesticides. Thing is, some of these pesticides persist, and well, humans are
----
> Which is bull, because all these languages, even assembler, are computationally equivalent (Turing complete). It is just more work and uglier to achieve.
/compiler/ in a Turing-complete way. (and no, #defines are not Turing complete, nor they can parse their arguments).
No, the original poster is quite right. Code generation and evaluation means that a LISP program can parse and rewrite itself. The 'rewrite' part is possible but ugly as hell in C (dump the source, exec the compiler, dl_open... you get the idea?). LISP macrosystem and Scheme syntax transformer allow you to modify the
--
Okay, my wishlist for the next spring:
- a handheld or a wearable
- retinal display for it
- a compact 802.11b receiver
And... Time to clean up my rollerblades!
The necessary support for this is in the XFree86 CVS already. There is a screenshot (check the Hello World! window) and the source code for this. Don't worry, Keith Packard has thought of everything. ;)
There's also SART, the renderer I'm working on. Its current focus is rendering, but there'll be a modeller in a, well, not too near future. Unfortunately I don't have the time to work on it as much as I'd like.
Current features are full programability (using guile), support for NURBS, blobs, parametric and implicit surfaces, volume rendering (including nonuniform textured volumes), radiosity, postprocessing. Check http://petra.zesoi.fer.hr/~silovic/sart for more info.
---
In fact you -can- inherit from any gtk+ class. While C, in itself, is not object oriented, gtk+ is - it's an OO system built on top of C. The main difference is that it exists on semantic level, rather than syntactic.
It supports inheritance, encapsulation, messaging, signals, exportable properties, and dynamic class identification.
Actually they are solvable in the sense that 'solution exists', not in the sense 'we can find the solution'. This is a distinction that was a topic of a rather sharp flamewar in the math community around 100 years ago. IIRC it was Hilbert who gave the first proof that was purely existential (i.e. it proved that something existed without a slightest hint as to how it might be found - the problem was one in algebraic geometry).
Actually I read the patent. It doesn't cover MDCT nor DCT at all. However, it pretty much covers the Huffman codes.
Can we say 'bogus'?
--
Actually there is an answer to that: Open Source. A small gaming company can safeguard against being clobbered and at the same time ensure external development help by going OSS from *early* stages (rather than OSSing old titles that aren't profitable any longer), and then make money by charging for gameserver access and selling packaged games (i.e. things that are added to the sources themselves: scenarios, graphics, etc).
:) ).
I'm talking from the experience - there will be an announcement soonish (can't go into details right now - wouldn't do for our website to get slashdotted before there is anything to download
> 1.For a project on the scale of Mozilla, can we realistically expect non-core developers to be useful in "early" stages?
The problem, IMHO, is not so much the size itself... it's rather modularity of the system. Most OSS project are either small-scale or have been designed from the beginning to be very modular, with *very* small module scale and limited module interaction. This means plugin/component architecture from the very start, and constrained interface complexity (i.e. it's predecided that components use VERY simple protocols to talk to each other).
Mozilla, currently, seems to have moved in this direction - it uses XPCOM and has IDL interfaces to all its internals. Unfortunately, it wasn't this way all the time, and the original monolythic Netscape sources were not merely daunting, as Mozilla's are, but nearly unworkable for the outsiders.
After the rewrite of the entire system, things cleared up a lot - Mozilla's internals are pretty close to Mnemonic's (the OSS browser designed for modularity). Unfortunately at this point (early 1999) the browser fell long behind schedule and so rumors of its early demise became prominent. Lately, however, there's been a noticable influx of the external developers to the effort - precisely because it's beginning to look managable.
--
Diffie-Hellman is not equivalent to RSA. It's vulnerable to man-in-the-middle attack. There are, however, some free assymetric algorithms that *can* be used - elliptic curves, for instance.
But the real problem is that many data-exchange standards (SSL, and MP3) *require* you to use patented technology. This is bad - you can't even save your data without violating a patent.
> For the Linux community outside of China, on the other hand, this could be bad. In the United States and in much of the rest of the world, we still fear the "red bastards" and every thing even slightly smelling of communism is seen as taboo and evil. Linux as an OS may be tainted by communism.
:)
Thing is... There are about billion people in China. And apart from piracy (not that they're too squemish about piracy, mind you - but then the only countries who really care about piracy are US and Western Europe, IMHO) they can't afford any other OS anyway. Say, 1% actually get an access to computer and one in thousand of these contribute to development. That's 10,000 developers - I wouldn't call it bad.
So what if your kernel calls you 'comrade'?
--
This reminds me of kernel-2.2. Sure, it took two years. Was it worth the wait? Definitely.
Mozilla is *not* going to be shipped before it's ready. I've played with the latest releases, and I can only say I'm impressed by what it does (hint: incremental table rendering - you can read Slashdot page with 200 comments in a second that it takes to fetch the first comment, while it proceeds to read the rest of them). In fact, surfing the web with Mozilla is as exhillerating as it used to be with Netscape-1.0 after Mosaic.
So, I for one prefer to wait for a browser that is a killer than to get almost-Netscape-but-not-quite-there rushed hack.
---
> But it is very likely that Berlin will have an X compatibility layer (it won't get any widespread adoption otherwise). Then, GTK/QT will work, and so will all the apps, then you can start porting GTK/QT to Berlin if you want, and there ya go, a group of developers don't ever notice the transition.
/once/.
/heard/ about it was Rasterman and he told me he couldn't grasp its API. Neither could I.
Meaning you get even slower and more bloated double-windowed system. At least extending X means you do things
Not that it's really needed. X has builtin image processing. Ever heard of Xie? No, not the X Input Extension, there is another one called X Image Extension. Unfortunately the only person I talked with who
The point being, why bother? X has it all. XFree86 doesn't support antialiesed font rendering, however, that has been worked on (I read somewhere that the code is currently commented out because they lack developers). And also, don't whine. If you don't like X, help XFree people to make it into what you like.