When you are installing from installshield, you're basically saying: 'Hello random executable from the internet (even if you are signed by someone), here, overwrite any of my libraries you'd like, with whatever obscure or customised version you want. Oh, and while you're at it, do whatever you want to my registry...'
And how is this different from: 'Hello random package from the repository (even if you are signed by the distro maintainers), here, overwrite any of my libraries you'd like, with whatever obscure or customised version (think distro-specific patches) you want. Oh, and while you're at it, do whatever you want to my/etc (from your postinstall script, running as root)...'
What makes the package maintainers inherently more trustable than the upstream developers who wrote the damn thing in the first place?
Re:Dear Lord make the madness stop!
on
Effective XML
·
· Score: 1
Again, you fall prey to using trivial examples to argue something which applies to more complex documents.
Even then, you still fail it. Your echo() example has a bug again! You have an <items> element that is being terminated by </item>.
Also, you don't do DOM justice in your DOM example, it can be simplified. You also have a bug in it also, you never attach the $items element enywhere, so I don't know how exactly your XML is supposed to look like.
My PHP is very rusty, but I'll try to indulge your apparent fondness for trivial examples. I know you can certainly simplify things by stringing DOM calls together, to create whole branches of your XML in one go, like this:
$dom->appendChild($dom->createElement("root"))-> ap pendChild($dom->createElement("section"))->setAttr ibute("id", "1");
Also, I'm not sure if PHP allows in-place assignment, or white-space after the method call operator (->), but in languages like Java/C++/C#/etc you can do something like this:
That is, create the XML branch and assign various sub-nodes to variables for later use in one go. As a bonus, you also make your code follow the tree-like structure of your XML. This way your code ends up manipulating (and looking like) tree fragments.
Atleast for me (and I suspect I'm not alone), it's much more natural to think of the XML as a tree-like structure of nodes that I manipulate.
The human brain is not a stack-based machine, and thinking of XML as a nested series of open/close tags is much less intuitive, as you demonstrated by bungling your close tag in your echo() example. It's not that you can't do it, but why burden your mind with banalities like remembering the proper close tag at a given point, or remembering to escape values, when you can apply it to higher level problems? Let the machine handle the mechanical details.
One additional bonus of using the DOM API is that the XML can optionaly be output indented by any half-decent DOM serializer, which makes the generated XML easier to debug in protocol dumps or whatever.
Just dump the output through xmllint or view it in a web browser.
Never said it was the ultimate advantage, just a minor bonus of using DOM.
Trying to generate properly indented XML from nested if/for/whatever code split accross multiple functions
That's downright disingenuous. DOM routines can also be in "nested if/for/whatever code split across multiple functions". How that code is arranged is utterly irrelevent, it's how the output can be arranged that matters, and there is no difference between the two methods in this respect.
I'm sorry, this is just wrong. With your echo() approach, generating properly indented XML is more difficult, because you have to pass a "whitespace" or a "level of nesting" parameter around in your multiple functions for generating the XML text. With DOM, you do no such thing. You just pass your nodes around as usual, and the indentation is done by DOM at the end.
Anyway, nobody said it is impossible to produce correct XML code with the echo() approach, but it is definitely more bug-prone, and you'll end up wasting more time going back to your code and fixing those bugs. Your repeated failure to produce correct XML code in even the most simplistic examples is an excellent illustration of my point.
And no, "we'll catch it in testing" is not an excuse for writing shoddy code in the first place, when there are better code practices to help you and guide you along the way.
P.S. Sorry for not providing more complicated examples with namespaces etc.,
Re:Dear Lord make the madness stop!
on
Effective XML
·
· Score: 1
You're missing the point.
Errors in rarely used parts of the generated XML document can get past you easily.
Not if you test properly. In practice, I haven't found this to be a problem.
With the DOM approach, you don't have to test the minutiae of the XML generation part of the program. Instead, you can spend that time more productively by better testing other more relevant parts of your program logic. Also, the argument that generating XML directly is easier is true only for simple examples like this, it gets complicated pretty fast as your requirements grow more complex.
what if your $v variable sometimes gets a '<' character in it
I omitted the escaping because I couldn't remember off the top of my head which of the three(?) different PHP markup-escaping functions works for XML.
Exactly. With the DOM approach, you don't have to remember this. It's easy to miss it in more complex XML generation routines, and after you've done all the escaping and error checking that DOM already does for you, will your program really be that much more readable than the DOM approach?
Your program would fail immediately
Precisely. It's not a bug that goes unnoticed, it's a syntax error that you immediately fix.
Umm... no. Your program will get compiled (or parsed by the interpreter) like nothing is wrong. There will be no syntax error. I meant above that it would fail to generate proper XML as soon as it receives an incorrect character during runtime, which can happen well after development, when the program is already deployed to customers, and all that hassle could have been avoided by using APIs that were specificaly designed for XML parsing/generation/manipulation, which have been debugged and field-tested countless times before.
You won't catch this failure unless you specifically test for this type of escaping bug, for that exact variable. The more complex your XML generation routines, the more difficult to test each possible combination of program inputs to excercise each possible XML output. Multiply this with many XML generation routines and many programs. You will miss a test, sooner or later. It is naive to generalize from your simple example above, and to think that you can test everything. Sure, bugs will always happen, but why compound the problem when you can reduce the number of bugs ever so slightly by using safe APIs that can also make your code more organized?
Of course, DOM doesn't solve everything, you will still have tests even in the DOM case, but atleast the DOM API is a safety net that will catch and handle some of these most basic corner cases that your tests might miss.
I've been bitten with small stuff like this (not only XML related) enough times to know better than try to splice strings together to generate XML, or try to take other quick & dirty shortcuts in bigger programs. I learned the hard way that shortcuts don't always cut short.
One additional bonus of using the DOM API is that the XML can optionaly be output indented by any half-decent DOM serializer, which makes the generated XML easier to debug in protocol dumps or whatever. Trying to generate properly indented XML from nested if/for/whatever code split accross multiple functions would require non-trivial additional effort better spent elsewhere.
And it's not only simple things like escaping variables or mismatching tags... when you also factor in namespace handling in complex documents with multiple namespaces, the DOM API with its automatic hierarchical namespace & prefix management starts to look really good. Similar arguments apply to XML entities, processing directives, CDATA, etc.
Re:Dear Lord make the madness stop!
on
Effective XML
·
· Score: 1
Not always. As soon as you start dealing with more complex XML, which can contain certain optional elements depending on complex conditions, things will get messy. Errors in rarely used parts of the generated XML document can get past you easily.
Also, even if the tags in your example are correct, your code still has a serious bug: what if your $v variable sometimes gets a '<' character in it (e.g. as a result of user input)? Your program would fail immediately, whereas DOM automatically escapes such characters before inserting the text into the document tree. You just proved how easy it is to introduce bugs using your method.
I do appreciate the concept of LISP-like closures, but in this context it's meaningless.
Anonymous classes are used only as a shorthand for defining the class elsewhere and then passing it as a parameter to some method. They are NOT closures, nor were they ever meant to be. Think about it, if you defined the class separately, instead of as anonymous, would you have access to local variables from another class' method then?
Having said that, the local values from the method where you defined the anon. class do exist in read-only form if you declare them final, purely as a convenience (another shorthand). You would accomplish the same effect by passing them as parameters to the constructor of a separately-defined non-anonymous class.
Don't confuse shorthand with a completely new semantic. The only place in Java where anon. classes are really used is for simple callback functions, and closures would be overkill.
Trying to overload the concept of "anonymous class" in Java with the additional semantic of "closure" would just confuse and complicate things... it's not that kind of language.:)
Several people mentioned that C# and CLI specs are ECMA and ISO standards.
But which versions of these specs are described in those standards? It's my impression that these standard organizations don't change the standard every year, look at the period between various revisions of the C/C++ standards, etc.
Yet, Microsoft keeps releasing new versions of C# at a fairly rapid pace, which introduce some significant changes. Are the ECMA/ISO standards updated with each new version?
I'm not trying to troll or anything, I really don't understand how this is supposed to work.
Specifically, what is preventing Microsoft from releasing a version of C# that deviates from the standard (if the recent versions don't already do)? Should they decide to do so, there is nothing anyone can do really do about it, as their.NET implementation is de facto standard, and if the new versions of their development tools are made to support only this new version, I don't think developers will have much choice but to use the new non-ISO-standard versions, since they already have invested time and resources in the platform. Mono would not be an option, since by the own admission they don't plan to support the next version of the.NET platform fully.
So, you end up back on the Microsoft treadmill of incompatible upgrades, business as usual. I don't share the same confidence as many others here apparently do. Maybe I'm missing something here, I would appreciate any enlightenment on this matter.
Of course, the same thing is absolutely true with Java. The Java language and platform specification is completely at the whim of Sun Microsystems. I'm just wondering why people think that just because C#/CLI has been accepted as an ECMA/ISO standard, they think the situation is any different? C# and.NET in general is still very much subject to the control and whims of Microsoft.
In Java's defense, Sun atleast have a proven track record of keeping a relatively stable language and platform to build upon, with incremental changes that involve the developer community to a certain extent. We have yet to see such a commitment from Microsoft. I guess only time will tell.
Anonymous classes are mostly used for passing to some method, to be called later (callbacks), so by the time they are called, the local variables in the method where the anon. class was defined NO LONGER EXIST, as that method has finished executing.
ATI's control panel utility? That's it? That's your wildcard, the killer app that shows the trend towards.NET on the desktop?
Well, HP's drivers for some of its printers come with management utilities written in Java. Does it mean Java is also conquering the desktop then?
Examples like this are pointless. When we see companies like Adobe, Macromedia, etc. come out with new versions of applications written exclusively in.NET, then you might have a point. So far, I haven't seen any such indication.
Even Microsoft has yet to produce any significant desktop software written in.NET.
P.S. I'm not bashing the.NET platform itself, it's certainly a much nicer language and API than the Win32/MFC/COM crap, it's just that your theory and examples are flawed.
We evaluated writing a free Qt replacement, but reimplementing an API would most likely result in less efficient software and would have taken too long to implement. GNUstep, Wine and LessTif were other projects that had attempted to reimplement a proprietary API and just had a limited success after a long development history.
And then he went on to reimplement a proprietary API, namely.NET... how ironic.
Each message in a thread has a named HTML anchor, try this for instance. It will show the whole thread, but position you at an exact message in the middle.
The only problem is there is no easy way to get this URL, you have to find the anchor by looking at the HTML source (Firefox's "View Selection Source" feature helps a lot).
Also, if you click on the "Options" link by the individual message, you get a "Show original" link, which shows just the message, verbatim.
And from there, you can click on "View parsed", and see just the pretty message, without the rest of the thread.
So there's your deep-linking. I agree it's not obvious how to do it at the moment, but the ability is obviously still there. Give it some time, it's still a beta!
These quirks and the "Server Error" bugs are to be expected, they'll work it out.
As for the new browsing interface itself, I kinda like it. It integrates and borrows some stuff from their excellent Gmail interface.
It hides quoted text by default (you can expand it with single click), so you don't have to scroll through some morons quoting of a whole message just to add a few words, it keeps a history of groups you recently visited, it allows you to bookmark topics you are interested in, etc. I do find it an improvement over the old interface.
The only thing is the missing date search, I agree there, that was definitely useful feature. If enough people complain, maybe they'll bring it back.
Also, someone else complained that you cannot browse by group anymore... bullshit, it's staring you right in the face, it's the "Browse all of Usenet" link.
Here's an example of the distinction in Macedonian, translated word for word:
taa beshe tamu = she was there taa bila tamu = she allegedly was there (or "she was there, I'm told")
Similar forms exist for all other verbs.
In your language, which looks like Serbian if I'm not mistaken, I think there is no such distinction (but I may be wrong, don't know it that well).
As for for your question about the 4 past tenses you mentioned, yes, we do have additional past tenses similar to those, e.g. definite vs indefinite, and also finished vs. unfinished, i.e. forms for describing events that happened in the past and finished, versus events that started in the past and may still be ongoing. I didn't mention them as they were not relevant to the discussion.
or learning Choctaw, a language with two past tenses - one for giving information which is definitely true, the other for passing on material taken without checking from someone else.
For what its worth, my native language, Macedonian, has two past tenses almost exactly like the above: one for things you personally witnessed, and the other for things you don't know first hand but think are true.
I find this quite natural. Imagine like having a separate past tense form for "she was there" as opposed to "she supposedly was there".
I was amazed to find a "Comment on the story" link at the bottom of the People's Daily article. Could it be? They would actually allow people to freely post their opinion on their prominent site?
Well, I wrote a comment asking why the minor fact of the satellite crashing through someone's freaking living room was silently ommited, but when I tried to submit it I got a page saying "Database query error"...
How can you speak like that? The nternet fraud in Macedonia was in global percantage so dismissable small that this country in now way deserved to be in this way. In comparesment with the US $54 billion fraud industry we are not evean a half a drop in the see. Especialy becuse no fraud sites exist under macedonian domains, nor are there any such sites by macedonians elswere.
Just because the fraud generated in Macedonia is a tiny percentage of the whole world, it is no excuse to do it.
What is more important is the ratio of legitimate orders to fradulent orders coming from here. If it is too low, then it's cheaper for a business to just block us completely than deal with each order individually.
I think it's paranoid to assume our whole country is somehow being "wrongfully punished" by the world just because some sites decided to indiscrimnately block traffic based on outdated blacklists based on past reputation. It's their loss, they are losing a potential market (however small). Once they realize it's not in their favor to do this, the blocking will stop.
The irony of this all is that big commercial internet companys do not block Macedonian Ip's, they just don't deliver to Macedonia. That's the consequence of the credit card frauds 7 years ago!
Not true. They just don't accept credit cards from Macedonia, you can still order by bank wire transfer and you will get it.
Further, it has come to my knowlege (news groups) that AOL and some otehr big US ISPs block access to macedonian sites. Absurdly these sits have nothing to do with money frauds or anything similar. They block goverment sites. The official sites of the Ministry departments.
I am not aware of any such blocking. Provide the URLs to Macedonian sites you think are blocked, and I'll check them. I have administrative access to a few machines in the US at a company I work for, and I'll check whether they are accessible from there.
don't know about you, but to me this looks like an attempt for political, social and overall isolation.
I doubt it.
I tend to not ascribe to malice, the things which can be explained by incompetence.
It's my (slashdotted) country, you insensitive clod!:)
Joking aside, you're not being insensitive at all, in fact you're quite right. My country's past reputation in this regard is anything but stellar. These days, however, things are incomparably better (new legislation, police much more alert to these types of crimes, etc.)
I expect that as things get better and retailer's confidence rises, the name Macedonia will slowly disappear from those blacklists.
Many online retailers don't accept credit cards from Macedonia for instance, instead requiring payment by direct wire transfer to a bank account. It's a real pain in the butt, as international wire transfers can add more than 30$ to the price you have to pay, so you have to group many things together in a single order, from a single shop, in order to not pay too much (shipping costs to here are already high enough).
This limits the choice of things you can order online, as you can't just order different items from different places, the combined wire transfer fee for each order would be way too much, you have to make sure everything is in big orders from small number of places.
The issue came to the public attention about 6-7 years ago (I think), when a bunch of teenagers "discovered" IRC CC trading channels, and got a hold of some stolen credit cards (and once you have a few, you can trade them with people on those channels to get more). They immediately shared them with their friends and started ordering all kinds of stuff online like CDs, watches, perfumes, eyeglasses, and what not, for them, their girlfriends, relatives, etc.
Well, the customs officials noticed the unusual surge in that kind of merchandise coming from a small number of big online retailers, and stemmed the flow immediately.
They would just keep the stuff at customs terminals, and notify the recipients that they should come pick it up. When a kid showed up, they simply asked for proof of order, and if it was ordered via credit card, they asked to see the actual credit card.
If they failed to produce it, the police was notified (the idiots were ordering stuff to their home addresses), and some of the bigger offenders were brought in for interrogation etc. Nobody really got anything more than a slap on the wrist, as most of them were just kids, but it sure ended the massive ordering.
I even remember even a few scary looking guys in suits with laptops at the university where I was studying then, they were going over the computer terminals and servers to extract logs of suspicious activity as some of the orders were coming from there. I later found out they were from the illegal trade department, which means somebody in the police took this very seriously.
In any case, I was surprised at how quickly this was stopped and the responsible people identified, I didn't think the customs and police had any kind of tech savy people among them.:)
On a related note, at about the same time software piracy was thriving in Macedonia, you could get a truck load of latest expensive software for a couple of dollars per CD.
It was really bad, I even distinctly remember I was playing the final retail version of Quake 2 almost a whole WEEK before it was scheduled to appear in US stores:)
Anyway, after some more incidents and complaints by foreign companies, the government really cracked down on this kind of thing a few years ago, and the legislation was slowly brought up to speed to include laws for online commerce, credit card fraud, etc.
Things are very much under control now, but hey, bad reputation (admittedly well deserved) tends to follow you for a long time...
I don't think I've noticed any of this blocking described in the article during my everyday surfing, and I do surf the web a lot. Can't say this really worries me.
While I do agree that blocking ANY country (including the mentioned Russia, Israel, etc.) based on actions of a few individuals is utterly wrong, I think the article is a bit too alarmist and paranoid, especially the bit about this being the result of some kind of political conspiracy.
So a few sites blocked Macedonian IPs, big deal. Various IP blocks get blocked all the time for various (sometimes wrong) reasons, and things usually work out when enough legitimate users complain. A tempest in a teapot...
Did you make transfers of all three original episodes? Is there a way I could get a copy of them? I only have old worn out VHS tapes, with no way of getting the originals on any other more permanent medium.:(
Slashdot Mirror
When you are installing from installshield, you're basically saying: 'Hello random executable from the internet (even if you are signed by someone), here, overwrite any of my libraries you'd like, with whatever obscure or customised version you want. Oh, and while you're at it, do whatever you want to my registry...'
/etc (from your postinstall script, running as root)...'
And how is this different from: 'Hello random package from the repository (even if you are signed by the distro maintainers), here, overwrite any of my libraries you'd like, with whatever obscure or customised version (think distro-specific patches) you want. Oh, and while you're at it, do whatever you want to my
What makes the package maintainers inherently more trustable than the upstream developers who wrote the damn thing in the first place?
Even then, you still fail it. Your echo() example has a bug again! You have an <items> element that is being terminated by </item>.
Also, you don't do DOM justice in your DOM example, it can be simplified. You also have a bug in it also, you never attach the $items element enywhere, so I don't know how exactly your XML is supposed to look like.
My PHP is very rusty, but I'll try to indulge your apparent fondness for trivial examples. I know you can certainly simplify things by stringing DOM calls together, to create whole branches of your XML in one go, like this:
$dom->appendChild($dom->createElement("root"))-> ap pendChild($dom->createElement("section"))->setAttr ibute("id", "1");
Also, I'm not sure if PHP allows in-place assignment, or white-space after the method call operator (->), but in languages like Java/C++/C#/etc you can do something like this:
dom.appendChild(root = dom.createElement("root")).
appendChild(items = dom.createElement("items")).
appendChild(whatever = dom.createElement("whatever")).setAttribute("blah" , "23);
That is, create the XML branch and assign various sub-nodes to variables for later use in one go. As a bonus, you also make your code follow the tree-like structure of your XML. This way your code ends up manipulating (and looking like) tree fragments.
Atleast for me (and I suspect I'm not alone), it's much more natural to think of the XML as a tree-like structure of nodes that I manipulate.
The human brain is not a stack-based machine, and thinking of XML as a nested series of open/close tags is much less intuitive, as you demonstrated by bungling your close tag in your echo() example. It's not that you can't do it, but why burden your mind with banalities like remembering the proper close tag at a given point, or remembering to escape values, when you can apply it to higher level problems? Let the machine handle the mechanical details.
Never said it was the ultimate advantage, just a minor bonus of using DOM.
I'm sorry, this is just wrong. With your echo() approach, generating properly indented XML is more difficult, because you have to pass a "whitespace" or a "level of nesting" parameter around in your multiple functions for generating the XML text. With DOM, you do no such thing. You just pass your nodes around as usual, and the indentation is done by DOM at the end.
Anyway, nobody said it is impossible to produce correct XML code with the echo() approach, but it is definitely more bug-prone, and you'll end up wasting more time going back to your code and fixing those bugs. Your repeated failure to produce correct XML code in even the most simplistic examples is an excellent illustration of my point.
And no, "we'll catch it in testing" is not an excuse for writing shoddy code in the first place, when there are better code practices to help you and guide you along the way.
P.S. Sorry for not providing more complicated examples with namespaces etc.,
With the DOM approach, you don't have to test the minutiae of the XML generation part of the program. Instead, you can spend that time more productively by better testing other more relevant parts of your program logic. Also, the argument that generating XML directly is easier is true only for simple examples like this, it gets complicated pretty fast as your requirements grow more complex.
Exactly. With the DOM approach, you don't have to remember this. It's easy to miss it in more complex XML generation routines, and after you've done all the escaping and error checking that DOM already does for you, will your program really be that much more readable than the DOM approach?
Umm... no. Your program will get compiled (or parsed by the interpreter) like nothing is wrong. There will be no syntax error. I meant above that it would fail to generate proper XML as soon as it receives an incorrect character during runtime, which can happen well after development, when the program is already deployed to customers, and all that hassle could have been avoided by using APIs that were specificaly designed for XML parsing/generation/manipulation, which have been debugged and field-tested countless times before.
You won't catch this failure unless you specifically test for this type of escaping bug, for that exact variable. The more complex your XML generation routines, the more difficult to test each possible combination of program inputs to excercise each possible XML output. Multiply this with many XML generation routines and many programs. You will miss a test, sooner or later. It is naive to generalize from your simple example above, and to think that you can test everything. Sure, bugs will always happen, but why compound the problem when you can reduce the number of bugs ever so slightly by using safe APIs that can also make your code more organized?
Of course, DOM doesn't solve everything, you will still have tests even in the DOM case, but atleast the DOM API is a safety net that will catch and handle some of these most basic corner cases that your tests might miss.
I've been bitten with small stuff like this (not only XML related) enough times to know better than try to splice strings together to generate XML, or try to take other quick & dirty shortcuts in bigger programs. I learned the hard way that shortcuts don't always cut short.
One additional bonus of using the DOM API is that the XML can optionaly be output indented by any half-decent DOM serializer, which makes the generated XML easier to debug in protocol dumps or whatever. Trying to generate properly indented XML from nested if/for/whatever code split accross multiple functions would require non-trivial additional effort better spent elsewhere.
And it's not only simple things like escaping variables or mismatching tags... when you also factor in namespace handling in complex documents with multiple namespaces, the DOM API with its automatic hierarchical namespace & prefix management starts to look really good. Similar arguments apply to XML entities, processing directives, CDATA, etc.
Not always. As soon as you start dealing with more complex XML, which can contain certain optional elements depending on complex conditions, things will get messy. Errors in rarely used parts of the generated XML document can get past you easily.
Also, even if the tags in your example are correct, your code still has a serious bug: what if your $v variable sometimes gets a '<' character in it (e.g. as a result of user input)? Your program would fail immediately, whereas DOM automatically escapes such characters before inserting the text into the document tree. You just proved how easy it is to introduce bugs using your method.
I completely agree with you .
I do appreciate the concept of LISP-like closures, but in this context it's meaningless.
:)
Anonymous classes are used only as a shorthand for defining the class elsewhere and then passing it as a parameter to some method. They are NOT closures, nor were they ever meant to be. Think about it, if you defined the class separately, instead of as anonymous, would you have access to local variables from another class' method then?
Having said that, the local values from the method where you defined the anon. class do exist in read-only form if you declare them final, purely as a convenience (another shorthand). You would accomplish the same effect by passing them as parameters to the constructor of a separately-defined non-anonymous class.
Don't confuse shorthand with a completely new semantic. The only place in Java where anon. classes are really used is for simple callback functions, and closures would be overkill.
Trying to overload the concept of "anonymous class" in Java with the additional semantic of "closure" would just confuse and complicate things... it's not that kind of language.
Several people mentioned that C# and CLI specs are ECMA and ISO standards.
.NET implementation is de facto standard, and if the new versions of their development tools are made to support only this new version, I don't think developers will have much choice but to use the new non-ISO-standard versions, since they already have invested time and resources in the platform. Mono would not be an option, since by the own admission they don't plan to support the next version of the .NET platform fully.
.NET in general is still very much subject to the control and whims of Microsoft.
But which versions of these specs are described in those standards? It's my impression that these standard organizations don't change the standard every year, look at the period between various revisions of the C/C++ standards, etc.
Yet, Microsoft keeps releasing new versions of C# at a fairly rapid pace, which introduce some significant changes. Are the ECMA/ISO standards updated with each new version?
I'm not trying to troll or anything, I really don't understand how this is supposed to work.
Specifically, what is preventing Microsoft from releasing a version of C# that deviates from the standard (if the recent versions don't already do)? Should they decide to do so, there is nothing anyone can do really do about it, as their
So, you end up back on the Microsoft treadmill of incompatible upgrades, business as usual. I don't share the same confidence as many others here apparently do. Maybe I'm missing something here, I would appreciate any enlightenment on this matter.
Of course, the same thing is absolutely true with Java. The Java language and platform specification is completely at the whim of Sun Microsystems. I'm just wondering why people think that just because C#/CLI has been accepted as an ECMA/ISO standard, they think the situation is any different? C# and
In Java's defense, Sun atleast have a proven track record of keeping a relatively stable language and platform to build upon, with incremental changes that involve the developer community to a certain extent. We have yet to see such a commitment from Microsoft. I guess only time will tell.
As for me, give me Python, or give me death!
What purpose?
Anonymous classes are mostly used for passing to some method, to be called later (callbacks), so by the time they are called, the local variables in the method where the anon. class was defined NO LONGER EXIST, as that method has finished executing.
What is there to modify?
ATI's control panel utility? That's it? That's your wildcard, the killer app that shows the trend towards .NET on the desktop?
.NET, then you might have a point. So far, I haven't seen any such indication.
.NET.
.NET platform itself, it's certainly a much nicer language and API than the Win32/MFC/COM crap, it's just that your theory and examples are flawed.
Well, HP's drivers for some of its printers come with management utilities written in Java. Does it mean Java is also conquering the desktop then?
Examples like this are pointless. When we see companies like Adobe, Macromedia, etc. come out with new versions of applications written exclusively in
Even Microsoft has yet to produce any significant desktop software written in
P.S. I'm not bashing the
We evaluated writing a free Qt replacement, but reimplementing an API would most likely result in less efficient software and would have taken too long to implement. GNUstep, Wine and LessTif were other projects that had attempted to reimplement a proprietary API and just had a limited success after a long development history.
.NET... how ironic.
And then he went on to reimplement a proprietary API, namely
If you bothered to actually look at the links I provided, you would have noticed that they do in fact point to the beta service.
Who was the idiot that started this rumor?
Each message in a thread has a named HTML anchor, try this for instance. It will show the whole thread, but position you at an exact message in the middle.
The only problem is there is no easy way to get this URL, you have to find the anchor by looking at the HTML source (Firefox's "View Selection Source" feature helps a lot).
Also, if you click on the "Options" link by the individual message, you get a "Show original" link, which shows just the message, verbatim.
And from there, you can click on "View parsed", and see just the pretty message, without the rest of the thread.
So there's your deep-linking. I agree it's not obvious how to do it at the moment, but the ability is obviously still there. Give it some time, it's still a beta!
These quirks and the "Server Error" bugs are to be expected, they'll work it out.
As for the new browsing interface itself, I kinda like it. It integrates and borrows some stuff from their excellent Gmail interface.
It hides quoted text by default (you can expand it with single click), so you don't have to scroll through some morons quoting of a whole message just to add a few words, it keeps a history of groups you recently visited, it allows you to bookmark topics you are interested in, etc. I do find it an improvement over the old interface.
The only thing is the missing date search, I agree there, that was definitely useful feature. If enough people complain, maybe they'll bring it back.
Also, someone else complained that you cannot browse by group anymore... bullshit, it's staring you right in the face, it's the "Browse all of Usenet" link.
Here's an example of the distinction in Macedonian, translated word for word:
taa beshe tamu = she was there
taa bila tamu = she allegedly was there (or "she was there, I'm told")
Similar forms exist for all other verbs.
In your language, which looks like Serbian if I'm not mistaken, I think there is no such distinction (but I may be wrong, don't know it that well).
As for for your question about the 4 past tenses you mentioned, yes, we do have additional past tenses similar to those, e.g. definite vs indefinite, and also finished vs. unfinished, i.e. forms for describing events that happened in the past and finished, versus events that started in the past and may still be ongoing. I didn't mention them as they were not relevant to the discussion.
or learning Choctaw, a language with two past tenses - one for giving information which is definitely true, the other for passing on material taken without checking from someone else.
:)
For what its worth, my native language, Macedonian, has two past tenses almost exactly like the above: one for things you personally witnessed, and the other for things you don't know first hand but think are true.
I find this quite natural. Imagine like having a separate past tense form for "she was there" as opposed to "she supposedly was there".
99 things left to go.
I was amazed to find a "Comment on the story" link at the bottom of the People's Daily article. Could it be? They would actually allow people to freely post their opinion on their prominent site?
Well, I wrote a comment asking why the minor fact of the satellite crashing through someone's freaking living room was silently ommited, but when I tried to submit it I got a page saying "Database query error"...
How convenient!
Am I on my own on this one?
Yup, pretty much.
How can you speak like that? The nternet fraud in Macedonia was in global percantage so dismissable small that this country in now way deserved to be in this way. In comparesment with the US $54 billion fraud industry we are not evean a half a drop in the see. Especialy becuse no fraud sites exist under macedonian domains, nor are there any such sites by macedonians elswere.
Just because the fraud generated in Macedonia is a tiny percentage of the whole world, it is no excuse to do it.
What is more important is the ratio of legitimate orders to fradulent orders coming from here. If it is too low, then it's cheaper for a business to just block us completely than deal with each order individually.
I think it's paranoid to assume our whole country is somehow being "wrongfully punished" by the world just because some sites decided to indiscrimnately block traffic based on outdated blacklists based on past reputation. It's their loss, they are losing a potential market (however small). Once they realize it's not in their favor to do this, the blocking will stop.
The irony of this all is that big commercial internet companys do not block Macedonian Ip's, they just don't deliver to Macedonia. That's the consequence of the credit card frauds 7 years ago!
Not true. They just don't accept credit cards from Macedonia, you can still order by bank wire transfer and you will get it.
Further, it has come to my knowlege (news groups) that AOL and some otehr big US ISPs block access to macedonian sites. Absurdly these sits have nothing to do with money frauds or anything similar. They block goverment sites. The official sites of the Ministry departments.
I am not aware of any such blocking. Provide the URLs to Macedonian sites you think are blocked, and I'll check them. I have administrative access to a few machines in the US at a company I work for, and I'll check whether they are accessible from there.
don't know about you, but to me this looks like an attempt for political, social and overall isolation.
I doubt it.
I tend to not ascribe to malice, the things which can be explained by incompetence.
It's my (slashdotted) country, you insensitive clod! :)
Joking aside, you're not being insensitive at all, in fact you're quite right. My country's past reputation in this regard is anything but stellar. These days, however, things are incomparably better (new legislation, police much more alert to these types of crimes, etc.)
I expect that as things get better and retailer's confidence rises, the name Macedonia will slowly disappear from those blacklists.
Many online retailers don't accept credit cards from Macedonia for instance, instead requiring payment by direct wire transfer to a bank account. It's a real pain in the butt, as international wire transfers can add more than 30$ to the price you have to pay, so you have to group many things together in a single order, from a single shop, in order to not pay too much (shipping costs to here are already high enough).
This limits the choice of things you can order online, as you can't just order different items from different places, the combined wire transfer fee for each order would be way too much, you have to make sure everything is in big orders from small number of places.
Other than that, it's no big deal.
The issue came to the public attention about 6-7 years ago (I think), when a bunch of teenagers "discovered" IRC CC trading channels, and got a hold of some stolen credit cards (and once you have a few, you can trade them with people on those channels to get more). They immediately shared them with their friends and started ordering all kinds of stuff online like CDs, watches, perfumes, eyeglasses, and what not, for them, their girlfriends, relatives, etc.
:)
:)
Well, the customs officials noticed the unusual surge in that kind of merchandise coming from a small number of big online retailers, and stemmed the flow immediately.
They would just keep the stuff at customs terminals, and notify the recipients that they should come pick it up. When a kid showed up, they simply asked for proof of order, and if it was ordered via credit card, they asked to see the actual credit card.
If they failed to produce it, the police was notified (the idiots were ordering stuff to their home addresses), and some of the bigger offenders were brought in for interrogation etc. Nobody really got anything more than a slap on the wrist, as most of them were just kids, but it sure ended the massive ordering.
I even remember even a few scary looking guys in suits with laptops at the university where I was studying then, they were going over the computer terminals and servers to extract logs of suspicious activity as some of the orders were coming from there. I later found out they were from the illegal trade department, which means somebody in the police took this very seriously.
In any case, I was surprised at how quickly this was stopped and the responsible people identified, I didn't think the customs and police had any kind of tech savy people among them.
On a related note, at about the same time software piracy was thriving in Macedonia, you could get a truck load of latest expensive software for a couple of dollars per CD.
It was really bad, I even distinctly remember I was playing the final retail version of Quake 2 almost a whole WEEK before it was scheduled to appear in US stores
Anyway, after some more incidents and complaints by foreign companies, the government really cracked down on this kind of thing a few years ago, and the legislation was slowly brought up to speed to include laws for online commerce, credit card fraud, etc.
Things are very much under control now, but hey, bad reputation (admittedly well deserved) tends to follow you for a long time...
I don't think I've noticed any of this blocking described in the article during my everyday surfing, and I do surf the web a lot. Can't say this really worries me.
While I do agree that blocking ANY country (including the mentioned Russia, Israel, etc.) based on actions of a few individuals is utterly wrong, I think the article is a bit too alarmist and paranoid, especially the bit about this being the result of some kind of political conspiracy.
So a few sites blocked Macedonian IPs, big deal. Various IP blocks get blocked all the time for various (sometimes wrong) reasons, and things usually work out when enough legitimate users complain. A tempest in a teapot...
Did you make transfers of all three original episodes? Is there a way I could get a copy of them? I only have old worn out VHS tapes, with no way of getting the originals on any other more permanent medium. :(
Please contact me at grnch@gmx.net
Please!