## I think you underestimate the ability of people to write bad code
but i don't.
good python code is extremely readable, and medium python code is a pleasure to WRITE, because many things just seem to solve themselves.
BUT, writing big software or maintaining medium-to-crappy python code is far worse than many of the alternatives (except perl, of course)... this is exactly why i have become such a big fan of type inference, not to speak of garbage collection which i had my doubts about in the past, but fully embrace nowadays.
python's shady object-orientation makes many things harder than they need be (compare ruby).
lacking private/public flags for methods
ugly "__something__" pseudo-access-control
implicit creation of attributes on write-access (*hello typos*)
not so beautiful handling of "method not implemented" functionality
incessant and visually displeasing explicit "self." everywhere
lacking abstract/virtual classes, interfaces
too frequent "necessity" of metaclass-hacks (although the possibility is very nice)
verbose attribute initialization in constructors
the evil "param = []" default value pitfall
and other defects with python's object system have led me to believe that it is not an ideal language for big-scale OO development.
yet, for rapid prototyping i know few languages that allow the programmer such unhindered experimentation and the *possibility* of resulting readable code. also for applications of a few thousand lines, written by a few people it can actually create a certain fun factor!
i agree that python has a tendency (at least for me) to cause relaxation and make even otherwise boring tasks fun due to its extremely readable nature and good balance of write-once vs. read-often.
and also, c++ is not such a hard competition when "having fun" is on your agenda. every single time that i sit down to program c++ i end up heavily frustrated at some point due to wrong "#include" order, some whacko unreadable compiler error or simply a hard to find segfault (most often due to forgotten pointer initialization, *will i ever learn*)...
yet, python tends to have its own set of problems, mainly stemming from the fact that NO type checking is done at startup time and so you have to start your program again and again, everytime only finding/fixing one small typo! certainly most of this problem can be eliminated by good unit testing practices, but a little more help from the interpreter/compiler would still be nice at times.
my current craze is for languages with type inference (standard ml, ocaml, haskell), which for me combine the cozy compiler assistance of typed languages with many/most of the liberties of dynamically types languages like ruby, python, perl, lisp, scheme...
well, except for restrictive languages like c++ and java (i don't know cobol personally;-), programming can be fun in any of the above languages (well, maybe not perl, but that's a question of personal taste).
## rewriting everything excepts the tests is an usual form of "refactoring" in Pugs:-)
probably not least due to the nice isolation/interchangability of functions in haskell... i haven't looked at the code yet, but heard that you were using monadic parser combinators, and if those things are good for one thing then it surely is extending, rewriting and "recombinating" sub-parsers *gg*
on a sidenote, here's a funny thing i found in an otherwise quite convincing C# tutorial (http://www.softsteel.co.uk/tutorials/cSharp/lesso n22.html) concerning closures and the perplexity they create in able imperative programmers:
Anonymous methods can also make use of the local variables and parameters in whose scope the anonymous method lies. This is a somewhat complicated, and we don't yet have a clear idea of when one should exploit it. So to illustrate it we'll borrow the example from the documentation.
It's important also to make committer sign-up fast and easy
new committers could be invited en masse and sign up on their own
committing quick and dirty protypes that can be refactored as they grow
*AAAHHHH* and i thought (quick and dirty) prototypes were supposed to be immediately scrapped and their essence implemented in clean, revised code... *silly me*
all in all an interesting read, commending "anarchy" and as-turbulent-as-possible commits over more stringent methodologies. i can imagine that PUGS is going along quite "smoothly" and am in awe how these two radically different communities (haskell and perl) managed to find each other;-)
but whether this community and flair can be reproduced simply by adhering to somewhat questionable guidelines is another question alltogether.
we can see that they have package a far from ready "xen 3.0" with their supposedly stable release of their distribution. maybe it really IS a more-or-less stable branch of the "still in development" xen cvs tree, but the xen developers don't see it fit yet to be released, so why should novell/suse?
i mean, maybe some of these "limitations" are really non-features/problems in the final xen3 (when it comes out), but this seriously doesn't sound all that great:
Graphics (AGP, DRM, 3D) don't work or even crash the machine
Hardware support is still limited (e.g. no PCMCIA)
ACPI support in Domain-0 is limited (e.g. no cpufreq)
32 Bit kernel is not PAE enabled
Full virtualization on VT not well tested
Other Operating System support on top of Xen and VT not tested
Microsoft has made a lot of very small innovations (often called "soft innovations"). Whether it's the ease of use of VB or the elegance of C# or the xml grammars used in the speech SDK
i might even concede your point - microsoft has indeed made several small innovations that by themselves are not much to look at, but in their entirety can make up a totally new style of working and collaborating...
but IMHO your examples suck!
"elegance of c#" is an insult to languages that might actually claim that attribute. C# is a conglomeration of diverse language features from all over the place without a coherent "metaphore". c#'s scripting features go well against its object-oriented origins and the cleanliness of its language specification - while still better than C++ - has no benefits over java.
please correct me if i'm wrong, but calling c# "elegant" is stretching it a bit, ain't it?
"ease of use of VB"; well, you can't argue about taste and there certainly are benefits to the integration of VB and the office suite and windows in general. but again "ease of use" is taking praise a bit too far; not even talking about the abomination of a language that is VB.
"xml grammars used in the speech SDK". i must admit that i haven't used them, but in my opinion xml (while being a nice "technology") is far over-hyped! using markup to represent code/data was an innovation of LISP and has been used before to great success. its use in the MS speech sdk might be comfortable and easy to use, but this (in my opinion) is just a case of good software development and good framework design than of talking about innovations! just by using the OO paradigm or design patterns my software doesn't automatically turn "innovative"; using known technology to achieve new aims is the right way to do it, but calling it "small innovations" is a bit over the top...
They've haven't been very accurate in the past about who has stockpiles of weapons.
yes, but remember that after a nuclear strike no evidence of these stockpiles will remain, therefore proving that they must have been there in the first place!
"Who controls the past, controls the future: who controls the present controls the past" - "1984"
Computer systems are much less faulty than humans for some kind of tasks.
and camera-based object recognition in bad lightning conditions with surface glare and low contrast is not necessarily one of them!
as an addon this system can (except for its price) not hurt to install, but once someone relies on it and cuts back the expenses allocated for human life guards, the unreliability of the system will kick in and (unless this system has been designed with the utmost care) will likely lead to more drownings than before its deployment!
think about issues like dirty camera glasses, packed pools where no two cameras can see any one swimmer, swimsuits that have a similar texture to water (esp. underwater), false alarms by children trying to stay underwater as long as they can (where a lifeguard might realize they are just fooling around),...
as an addon, this is a good thing, but hopefully this will not substitute any human lifeguard expenses in the near future!
No serious gamer is going to want to use Vista now
i hope you are right, and everyone will switch to "better" platforms;-))
but don't you think that it's FAR more likely that game designers will from now on design with ONLY direct3d in mind and that soon every gamer will have switched to vista and the possibility of game ports to other platforms will be reduced to 0???
i hope you are right and all the gamers stick to their windows xp/2000/98!
There are plenty of games out there, such as the original Command & Conquer and Red Alert, which aren't afraid to paint the West as the good guys and terrorists/the Soviets as the baddies
well, the funny thing about C&C is, that whilst it certainly is very opinionated about communism/udssr/russia it also allows to play either side of the struggle, thus making clear the subjectivity in such conflicts! i am not saying that this was their prime goal, but when you get this propaganda in C&C on the screen about the other side/the "bad" guys it really doesn't matter so much whether you are playing "the good ones or the evil ones". the other side is painted as evil and destructive and you are supposed to do anything in your might to "stop" them...
so, when playing both sides, this might even teach a little more tolerance on such ideological topics!
(well, it IS a video game and most likely won't have said effect)
a new vector has size 0 so it doesn't have any "values" to initialize
exactly! and as BS wrote in TFA, it would be quite nice to initialize vectors with more than 0 members; like so:
std::vector vec = {1,2,3};
this would be especially handy if the values between the braces above are not all the same (in which case one could use vector constructors default value)!
i am/was quite aware that you COULD somehow get values into a vector. but i resent the necessity of the 4-6 lines of code of yours.
wouldn't it be great to simply write:
std::vector vec = {1,2,3,4};
no matter whether it was pure syntactic sugar or however implemented, but this would elevate std::vectors to a built-in-status that they simply don't have today!
C was never a "nice" langauge, it was ugly, had massive problems around memory allocations, and the old unallocated pointer problems. It had unmangled names, so everything was in a global scope.
Then you had langauges like Smalltalk and Eiffel, elegant languages, simplicity, languages which gave control and power.
i won't dispute that many languages allow much better (data and functional) abstraction than C. but C - in its simplicity as a more readable and slightly more type-safe assembly - had its merits. in C there are no hidden mechanism and you are always right on the bare metal of the machine. so for what it was written for (operating systems, drivers and low-level software) C is actually a veritable and suitable language; far from more abstract languages in its power of abstraction and lacking any kind of real type-safety, BUT it had its applications!
c++ on the other hand takes the principles of C (medium/weak typing, ability to program close to the machine, lack of functional abstraction) and enhanced it by adding hidden mechanisms and arcane problems with values/references/pointers such as object slicing, double freeing, etc.
therefore c++ is neither the bare-metal-language that C was nor is it a real abstraction language like smalltalk, eiffel, lisp, haskell,...! it is a PITA to learn C++, because every time you think you got it, something else creeps up on you and leads to one of those beloved "segmentation faults". c++'s merit is, that it allows a seemless transition from the bare-metal-programming of C to the more abstract realms of genericity (via templates *argh*) and OO. but the cost of this wide spectrum is the impossibility to comprehend c++ in its entirety or even understand enough of it in order not to be clubbed to death by wild pointers and memory corruption.
on its own, the necessity to think about copy-constructors and assignment-operators for EVERY class one writes is annoying. but together with virtual function calls not working in con/destructors, expressions of form
Class instance();
being interpreted as function declarations and by-default-implicit constructors can bring the aspiring beginner close to the edge sometimes.
1. Member function pointers. Implementation dependent and messy syntax that few people even know about. Their use is limited, and they don't support delegates like C#, making them ugly to work with.
not having a way to initialize a std::vector with some values has always been one minor annoyance for me when using the stl containers!
and about that "expert" thing: it is not by chance that c++ has become an expert-oriented language! there are SO many hidden traps and arcane details to get wrong that one can't just use c++ with intermediate skills and hope not to be punished! even the most simple mistakes can (and will) lead to segmentation faults and memory corruption! i am not even saying that c++ is an evil language, but it sure as hell isn't newbie-friendly!
i am a student in germany and i am managing quite well with $800 per month. and although my accomodations are rather cheap, cost of living should be a lot lower over in south america!
but on the other hand i don't have a family to feed, nor can i afford any kind of luxury with that money. but it's enough money to live quite well on!
you seem to be very much in touch with your worst nightmares. maybe you should do some script writing for george lucas there!
BTW, those visions were awful, damn close to my personal nightmare of an ender's game movie adaptation. thanks for bringing this up so early, so i won't be shocked when the final film will actually be even worse!
to use scripting to determine, dynamically, where in a file to scan and detect threats.
1.) the term "dynamically" covers quite a lot, doesn't it? that ranges from "reading from the virus database at runtime" to "incredible advanced AI"
2.) so, will this patent cover all embedded scripting languages in virus scanner software?
maybe this is a novel concept and worth protecting (although i doubt it), but all in all i am very critical of patents threatening to push obvious solutions into illegality! "obvious" is certainly a very subjective classification as good and novel ideas go into the mainstream after some time and seem natural (cookies for example). but shouldn't "abstract" patterns be a little more specific than just "dynamically by scripting choose an area to scan"? there can't possibly have gone much "research" into this and if the research yielded concrete results then maybe THOSE should be patented in a very restricting manner!
this is a simple idea I'm surprised more people haven't been doing this more often.
*yeah, right* this "idea" is described in every single tutorial/howto/paper/note about password security. it's a good idea, i've been doing it for years, it has most likely been mentioned on slashdot countless times, but here we go again.
at times i forget why i am such an avid reader; it provides me with "stuff that matters" and makes me feel like i know more than all the others, from time to time;-)))
What the solution is is to only use tools that have safe buffers, where buffer size constraints are enforced at the compiler or execution level. There's no performance penalty inherent in such tools and they make the programmer's job easier.
well, depending on the implementation bounds checking can actually incur quite a noticeable performance penalty for huge arrays! the question is whether you'll accept your image loading.001 seconds longer for the certainty(?) of not getting buffer overflows.
bounds checking alone will eliminate a huge number of exploits, but will certainly not do away with the issue of general exploitability! there can always be weaknesses in the language implementation (even in the bounds checking at that). but getting rid of buffer overflows would certainly be a huge improvement.
and i have never gotten a XCF file in my mail. there is a difference between formats to exchange data and formats to store data!
it would be a shame if nothing else could read gimp's file, but it isn't so (libgimp,...). and XCF isn't a "closed" format, it just ain't very popular as a means of distributing images. microsoft DOC on the other hand is the de-facto-standard of formatted-text-distribution, is a binary, bloated piece of sh*t and not even readable by some m$ office's versions...
well, that is really a shame. i would have thought that the abiword guys had an import plugin for this...
- copy&paste between different applications
yes, this IS a serious drawback which stems from the different GUI toolkits. drag&drop also is very problematic between GTK/KDE/X11... but if you use KDE with KDE-applications this problem is much less worse;-(
- embbed an Gnumeric chart into some OpenOffice document
hmm, should this actually work? you mean like the COM stuff in windows (if that is the right buzzword;-)? this is not really intended under linux and thus an odd example. windows can't do many of the things that linux can do really well... there is enough lacking in linux to reduce the criticism only to the CORE problems;-)
- try to edit a LaTeX document with Abiword or OpenOffice
i haven't tried this because abiword nor openoffice are text editors, but it is perfectly possible to do so! or do you mean that abiword/OO should present the document in a LyX-like fashion? this is such a wrong approach!!! abiword/OO are word processors while latex is a typesetting system! two TOTALLY different domains! that would be like using the Internet Explorer as your default image viewer... *hey, wait a second*
- try to open a Gimp xcf in anything beside Gimp
XCF is an internal format of the Gimp just like PSD is for photoshop! these formats are not really intended to be opened by other programs!
- try to copy&paste some webpage in a Office application and get something more then plain-text
i never understood the urge to do so! my mother always does this as a means of pasting together different bits of information, but why would i want to paste the color, font and background image together with the text?? i am not saying that it is a useless feature and maybe it would be nice if it were possible under linux, but i really don't see any application for this! even worse, i'd REALLY like to know how to disable this questionable feature under windows!
*Yeah*, let's all use microsoft office because that's the only way to achieve interoperability between different parties!
unless i totally misunderstand that word, aren't open standards BETTER in terms of interoperability than closed, proprietary ones??
i say we publish official and open standards, protocols and file formats for all major interactions and make it everybodies choice whether they like to have an open client for the standardized communications or if they'd rather take proprietary tools!
obviously, not every program can be delivered with full source, but if a vendor wants to reach various platforms, there is either a common standard in place (like POSIX for example) or some porting is in order *tough luck*.
why did mr. gates fight java as language and instead went with.NET. i can assure you that interoperability is NOT the reason!
why would a quasi-monopolistic company preach interoperability when this can only weaken its own position???
Slashdot Mirror
but i don't.
good python code is extremely readable, and medium python code is a pleasure to WRITE, because many things just seem to solve themselves.
BUT, writing big software or maintaining medium-to-crappy python code is far worse than many of the alternatives (except perl, of course)... this is exactly why i have become such a big fan of type inference, not to speak of garbage collection which i had my doubts about in the past, but fully embrace nowadays.
python's shady object-orientation makes many things harder than they need be (compare ruby).
and other defects with python's object system have led me to believe that it is not an ideal language for big-scale OO development.
yet, for rapid prototyping i know few languages that allow the programmer such unhindered experimentation and the *possibility* of resulting readable code. also for applications of a few thousand lines, written by a few people it can actually create a certain fun factor!
that must be the article with the least content in my entire slashdot "career".
no thesis, no argument, no concrete examples of HOW to make software better or HOW to implement such liability.
i do understand this is a follow-up, but why exactly should ANYONE care about this mindless piece of crackpot-tery?
i agree that python has a tendency (at least for me) to cause relaxation and make even otherwise boring tasks fun due to its extremely readable nature and good balance of write-once vs. read-often.
;-), programming can be fun in any of the above languages (well, maybe not perl, but that's a question of personal taste).
and also, c++ is not such a hard competition when "having fun" is on your agenda. every single time that i sit down to program c++ i end up heavily frustrated at some point due to wrong "#include" order, some whacko unreadable compiler error or simply a hard to find segfault (most often due to forgotten pointer initialization, *will i ever learn*)...
yet, python tends to have its own set of problems, mainly stemming from the fact that NO type checking is done at startup time and so you have to start your program again and again, everytime only finding/fixing one small typo! certainly most of this problem can be eliminated by good unit testing practices, but a little more help from the interpreter/compiler would still be nice at times.
my current craze is for languages with type inference (standard ml, ocaml, haskell), which for me combine the cozy compiler assistance of typed languages with many/most of the liberties of dynamically types languages like ruby, python, perl, lisp, scheme...
well, except for restrictive languages like c++ and java (i don't know cobol personally
## rewriting everything excepts the tests is an usual form of "refactoring" in Pugs :-)
o n22.html) concerning closures and the perplexity they create in able imperative programmers:
probably not least due to the nice isolation/interchangability of functions in haskell... i haven't looked at the code yet, but heard that you were using monadic parser combinators, and if those things are good for one thing then it surely is extending, rewriting and "recombinating" sub-parsers *gg*
on a sidenote, here's a funny thing i found in an otherwise quite convincing C# tutorial (http://www.softsteel.co.uk/tutorials/cSharp/less
Anonymous methods can also make use of the local variables and parameters in whose scope the anonymous method lies. This is a somewhat complicated, and we don't yet have a clear idea of when one should exploit it. So to illustrate it we'll borrow the example from the documentation.
Embrace anarchy
It's important also to make committer sign-up fast and easy
new committers could be invited en masse and sign up on their own
committing quick and dirty protypes that can be refactored as they grow
;-)
*AAAHHHH*
and i thought (quick and dirty) prototypes were supposed to be immediately scrapped and their essence implemented in clean, revised code... *silly me*
all in all an interesting read, commending "anarchy" and as-turbulent-as-possible commits over more stringent methodologies. i can imagine that PUGS is going along quite "smoothly" and am in awe how these two radically different communities (haskell and perl) managed to find each other
but whether this community and flair can be reproduced simply by adhering to somewhat questionable guidelines is another question alltogether.
http://www.opensuse.org/Xen3_Status_and_Updates
we can see that they have package a far from ready "xen 3.0" with their supposedly stable release of their distribution. maybe it really IS a more-or-less stable branch of the "still in development" xen cvs tree, but the xen developers don't see it fit yet to be released, so why should novell/suse?
i mean, maybe some of these "limitations" are really non-features/problems in the final xen3 (when it comes out), but this seriously doesn't sound all that great:
i might even concede your point - microsoft has indeed made several small innovations that by themselves are not much to look at, but in their entirety can make up a totally new style of working and collaborating...
but IMHO your examples suck!
please correct me if i'm wrong, but calling c# "elegant" is stretching it a bit, ain't it?
just by using the OO paradigm or design patterns my software doesn't automatically turn "innovative"; using known technology to achieve new aims is the right way to do it, but calling it "small innovations" is a bit over the top...
They've haven't been very accurate in the past about who has stockpiles of weapons.
yes, but remember that after a nuclear strike no evidence of these stockpiles will remain, therefore proving that they must have been there in the first place!
"Who controls the past, controls the future: who controls the present controls the past" - "1984"
Computer systems are much less faulty than humans for some kind of tasks.
...
and camera-based object recognition in bad lightning conditions with surface glare and low contrast is not necessarily one of them!
as an addon this system can (except for its price) not hurt to install, but once someone relies on it and cuts back the expenses allocated for human life guards, the unreliability of the system will kick in and (unless this system has been designed with the utmost care) will likely lead to more drownings than before its deployment!
think about issues like dirty camera glasses, packed pools where no two cameras can see any one swimmer, swimsuits that have a similar texture to water (esp. underwater), false alarms by children trying to stay underwater as long as they can (where a lifeguard might realize they are just fooling around),
as an addon, this is a good thing, but hopefully this will not substitute any human lifeguard expenses in the near future!
No serious gamer is going to want to use Vista now
;-))
i hope you are right, and everyone will switch to "better" platforms
but don't you think that it's FAR more likely that game designers will from now on design with ONLY direct3d in mind and that soon every gamer will have switched to vista and the possibility of game ports to other platforms will be reduced to 0???
i hope you are right and all the gamers stick to their windows xp/2000/98!
There are plenty of games out there, such as the original Command & Conquer and Red Alert, which aren't afraid to paint the West as the good guys and terrorists/the Soviets as the baddies
well, the funny thing about C&C is, that whilst it certainly is very opinionated about communism/udssr/russia it also allows to play either side of the struggle, thus making clear the subjectivity in such conflicts!
i am not saying that this was their prime goal, but when you get this propaganda in C&C on the screen about the other side/the "bad" guys it really doesn't matter so much whether you are playing "the good ones or the evil ones". the other side is painted as evil and destructive and you are supposed to do anything in your might to "stop" them...
so, when playing both sides, this might even teach a little more tolerance on such ideological topics!
(well, it IS a video game and most likely won't have said effect)
a new vector has size 0 so it doesn't have any "values" to initialize
exactly!
and as BS wrote in TFA, it would be quite nice to initialize vectors with more than 0 members; like so:
std::vector vec = {1,2,3};
this would be especially handy if the values between the braces above are not all the same (in which case one could use vector constructors default value)!
thx.
i am/was quite aware that you COULD somehow get values into a vector. but i resent the necessity of the 4-6 lines of code of yours.
wouldn't it be great to simply write:
std::vector vec = {1,2,3,4};
no matter whether it was pure syntactic sugar or however implemented, but this would elevate std::vectors to a built-in-status that they simply don't have today!
C was never a "nice" langauge, it was ugly, had massive problems around memory allocations, and the old unallocated pointer problems. It had unmangled names, so everything was in a global scope.
...! it is a PITA to learn C++, because every time you think you got it, something else creeps up on you and leads to one of those beloved "segmentation faults". c++'s merit is, that it allows a seemless transition from the bare-metal-programming of C to the more abstract realms of genericity (via templates *argh*) and OO. but the cost of this wide spectrum is the impossibility to comprehend c++ in its entirety or even understand enough of it in order not to be clubbed to death by wild pointers and memory corruption.
Then you had langauges like Smalltalk and Eiffel, elegant languages, simplicity, languages which gave control and power.
i won't dispute that many languages allow much better (data and functional) abstraction than C. but C - in its simplicity as a more readable and slightly more type-safe assembly - had its merits. in C there are no hidden mechanism and you are always right on the bare metal of the machine. so for what it was written for (operating systems, drivers and low-level software) C is actually a veritable and suitable language; far from more abstract languages in its power of abstraction and lacking any kind of real type-safety, BUT it had its applications!
c++ on the other hand takes the principles of C (medium/weak typing, ability to program close to the machine, lack of functional abstraction) and enhanced it by adding hidden mechanisms and arcane problems with values/references/pointers such as object slicing, double freeing, etc.
therefore c++ is neither the bare-metal-language that C was nor is it a real abstraction language like smalltalk, eiffel, lisp, haskell,
on its own, the necessity to think about copy-constructors and assignment-operators for EVERY class one writes is annoying. but together with virtual function calls not working in con/destructors, expressions of form
Class instance();
being interpreted as function declarations and by-default-implicit constructors can bring the aspiring beginner close to the edge sometimes.
1. Member function pointers. Implementation dependent and messy syntax that few people even know about. Their use is limited, and they don't support delegates like C#, making them ugly to work with.
( )), v));
exactly, and
std::for_each(content.begin(), content.end(),
std::bind1st(std::mem_fun(&PointVisitor::operator
is neither typable nor easy to read AT ALL! plus, it makes my head ache!
if that were to happen i'd *so* be exhilerated!
not having a way to initialize a std::vector with some values has always been one minor annoyance for me when using the stl containers!
and about that "expert" thing: it is not by chance that c++ has become an expert-oriented language! there are SO many hidden traps and arcane details to get wrong that one can't just use c++ with intermediate skills and hope not to be punished! even the most simple mistakes can (and will) lead to segmentation faults and memory corruption!
i am not even saying that c++ is an evil language, but it sure as hell isn't newbie-friendly!
it's actually quite easy to calculate:
;-)
10% of $741 = $74
$36 is about half of that so you divide by 1/2
10% / 0.5 = 20%
i am a student in germany and i am managing quite well with $800 per month. and although my accomodations are rather cheap, cost of living should be a lot lower over in south america!
but on the other hand i don't have a family to feed, nor can i afford any kind of luxury with that money. but it's enough money to live quite well on!
jethr0
you seem to be very much in touch with your worst nightmares.
maybe you should do some script writing for george lucas there!
BTW, those visions were awful, damn close to my personal nightmare of an ender's game movie adaptation. thanks for bringing this up so early, so i won't be shocked when the final film will actually be even worse!
jethr0
to use scripting to determine, dynamically, where in a file to scan and detect threats.
1.) the term "dynamically" covers quite a lot, doesn't it? that ranges from "reading from the virus database at runtime" to "incredible advanced AI"
2.) so, will this patent cover all embedded scripting languages in virus scanner software?
maybe this is a novel concept and worth protecting (although i doubt it), but all in all i am very critical of patents threatening to push obvious solutions into illegality! "obvious" is certainly a very subjective classification as good and novel ideas go into the mainstream after some time and seem natural (cookies for example). but shouldn't "abstract" patterns be a little more specific than just "dynamically by scripting choose an area to scan"? there can't possibly have gone much "research" into this and if the research yielded concrete results then maybe THOSE should be patented in a very restricting manner!
this is a simple idea I'm surprised more people haven't been doing this more often.
;-)))
*yeah, right*
this "idea" is described in every single tutorial/howto/paper/note about password security. it's a good idea, i've been doing it for years, it has most likely been mentioned on slashdot countless times, but here we go again.
at times i forget why i am such an avid reader; it provides me with "stuff that matters" and makes me feel like i know more than all the others, from time to time
jethr0
What the solution is is to only use tools that have safe buffers, where buffer size constraints are enforced at the compiler or execution level. There's no performance penalty inherent in such tools and they make the programmer's job easier.
.001 seconds longer for the certainty(?) of not getting buffer overflows.
;-)
well, depending on the implementation bounds checking can actually incur quite a noticeable performance penalty for huge arrays! the question is whether you'll accept your image loading
bounds checking alone will eliminate a huge number of exploits, but will certainly not do away with the issue of general exploitability! there can always be weaknesses in the language implementation (even in the bounds checking at that). but getting rid of buffer overflows would certainly be a huge improvement.
apart from that, FULL ACK
and i have never gotten a XCF file in my mail.
...). and XCF isn't a "closed" format, it just ain't very popular as a means of distributing images. microsoft DOC on the other hand is the de-facto-standard of formatted-text-distribution, is a binary, bloated piece of sh*t and not even readable by some m$ office's versions...
there is a difference between formats to exchange data and formats to store data!
it would be a shame if nothing else could read gimp's file, but it isn't so (libgimp,
i see a HUGE difference there!
- open a OpenOffice document in AbiWord
;-(
;-)? this is not really intended under linux and thus an odd example. windows can't do many of the things that linux can do really well... there is enough lacking in linux to reduce the criticism only to the CORE problems ;-)
well, that is really a shame. i would have thought that the abiword guys had an import plugin for this...
- copy&paste between different applications
yes, this IS a serious drawback which stems from the different GUI toolkits. drag&drop also is very problematic between GTK/KDE/X11... but if you use KDE with KDE-applications this problem is much less worse
- embbed an Gnumeric chart into some OpenOffice document
hmm, should this actually work? you mean like the COM stuff in windows (if that is the right buzzword
- try to edit a LaTeX document with Abiword or OpenOffice
i haven't tried this because abiword nor openoffice are text editors, but it is perfectly possible to do so! or do you mean that abiword/OO should present the document in a LyX-like fashion? this is such a wrong approach!!! abiword/OO are word processors while latex is a typesetting system! two TOTALLY different domains!
that would be like using the Internet Explorer as your default image viewer... *hey, wait a second*
- try to open a Gimp xcf in anything beside Gimp
XCF is an internal format of the Gimp just like PSD is for photoshop! these formats are not really intended to be opened by other programs!
- try to copy&paste some webpage in a Office application and get something more then plain-text
i never understood the urge to do so! my mother always does this as a means of pasting together different bits of information, but why would i want to paste the color, font and background image together with the text?? i am not saying that it is a useless feature and maybe it would be nice if it were possible under linux, but i really don't see any application for this! even worse, i'd REALLY like to know how to disable this questionable feature under windows!
jethr0
*Yeah*, let's all use microsoft office because that's the only way to achieve interoperability between different parties!
.NET. i can assure you that interoperability is NOT the reason!
unless i totally misunderstand that word, aren't open standards BETTER in terms of interoperability than closed, proprietary ones??
i say we publish official and open standards, protocols and file formats for all major interactions and make it everybodies choice whether they like to have an open client for the standardized communications or if they'd rather take proprietary tools!
obviously, not every program can be delivered with full source, but if a vendor wants to reach various platforms, there is either a common standard in place (like POSIX for example) or some porting is in order *tough luck*.
why did mr. gates fight java as language and instead went with
why would a quasi-monopolistic company preach interoperability when this can only weaken its own position???
jethr0