Are all botnet operators dumb? There's a whole heap of things botnet operators could do to insulate themselves and their networks from attack. Examples: [snip]
Like they actually need to. If the effort described in the article takes off, then perhaps it will become necessary. For now, the botnets thrive without going to such great lengths.
Can you expand your point about exposing too much SQL? My worst experience with a framework was with J2EE entity beans (EJB ver. 2.0.) - the persistence layer that tried to hide the SQL only to reimplement it totally half-assedly. The EQL sucked a big time:
- no mass updates/deletes.
- no aggregation (count,max,min,sum)
- no dynamic queries
- restricted joins
I've heard they fixed it to some degree in EJB ver. 3.0, getting it close to the actual SQL expression power.
Do you know a persistence framework that doesn't expose SQL and yet gives you the power that SQL does?
A "middle way" is to do what SWT does and wrap the native widgets with a generic API. This creates a "lowest common denominator" problem, however, since you inevitably have to stick to only using those widgets which all your target platforms have...
This "inevitably" is the consequence of forcing the full cross-platformness down the developer's throat. Yes, if you create One API and force the programmer to use it, the "lowest common denominator" problems are inevitable. But this isn't the only way. I use wxWidgets for my GUI apps. I can stick to the cross-platform API when I want a quick cross-platform GUI, but I can easily take advantage of the platform-specific hacks - they're just one GetHandle() call away. And my app can still be cross-platform, at least as long as I check the current platform before calling win32 or gtk-specific functions.
Perhaps because platform independence is one of the goals of Java, and so they can't assume that everyone is running Windows?
Yup, but this implies that their goals have to be my goals and their way of reaching the goals has to be my way - this is exactly the downside of chosing a platform. Perhaps I want to write my own platform-specific hacks? Perhaps I don't want the lowest common cross-platform denominator that Java provides?
I do cross-platform programming with wxWidgets, a library that still lets me access the underlying OS widgets. I get both platform independence and ability to work around an occasional platform-specific wxWidgets kludge. This of course doesn't mean that my app works only on windows.
The parent post made an important point, worth highlighting. Limitations. The "things that the framework fights you on" (quote from parent). Not what the framework just does not do, but what it effectively _prevents_ you from doing, or at least makes you jump through hoops to achieve it.
Singletons in the J2EE framework. Compare this monstrosity with a sigleton implementation in any sane language, including the simple, non-J2EE Java. Mind you, I'm not bashing J2EE here , the singleton issue is the price you pay for scalability.
Using Java for GUI on Windows. Most GUI libraries built on top of the winapi at least let you get the window handle from their widget implementations so that you can get straight through to win32 and do your hacking there (possibly fkcuing up the lib, since it doesn't know about your updates, but that's another issue:) ). This is not the case with Java - if a winapi function is not reflected in the Java API, you are pretty much screwed.
Persistence frameworks. "You won't have to write a single SQL statement for the rest of your life!". But if the statement generated by the framework is suboptimal, then guess what? Yup, screwed again.
Good luck choosing your framework. I hope I scared you to death, because, in my opinion you cannot be too scared of frameworks:)
Actually, we have three different professional recruiting agencies working for us. I still get crap. Nothing like paying a recruiter $50k for a marginal canidate that quits in under a year!
If you are unsatisfied with the screening, then don't accept the candidate. I assume you don't pay the agency unless you actually employ someone?
As to keeping commitment, do you expect the agency to guarantee that the guy doesn't quit? Seriously, it is the employer's and only employer's responsibility to keep the employees employed. You cannot outsource that.
Screened candidates? Oh, so companies want to hire someone to disqualify people for them? Three cheers for capitalism.
I would love to have a reliable outside source do what HR should do. I do actually get resumes from bus drivers that want to become engineers.
"Would love"? Are you ready to pay for it? Great! Contact a recruitment company. Online sites are not professional recruiters.
No funds? So you expect someone to do the screening work and give you free access to it online? Keep on dreaming.
...that said, the number of phone calls allowable should really be licensed on a per-CPU/core basis. If Skype honestly believes that Intel Duo chips with Intel's optimizations are truly twice as efficient as AMD's dual core chips, a license for 10 calls should be available for quad core AMD products. I have never been a fan of licensing by the number of CPUs, specifically disabling features if a host machine has fewer than X processors, but it has been in use for years.
I don't bash per-processor licensing, at least not as being anti-competitive, but I don't want Skype to judge what my processor is fit for. Just f.cking use the best compiler for each architecture and let me decide which processor I want. And if they want to extract more money from the big guys, they should licence per-concurrent-phone-call, as this is what they sell!
Anything other than that is just anti-consumer bullshit, with weak pseudo-techological excuses.
Isn't it about time some effort was put into making Java or Mono part of the system, so it can be shared like C apps do?
Huge effort required, with some hard design decisions looming ahead. Jar files store java bytecode, which is (usually) jit-compiled at runtime to native code by the VM. My guess is that sharing the bytecode alone isn't enough and probably happens already (A disk page read by several different processes is loaded into 1 physical memory page which is then mmap'ped by the OS to the processes' address spaces). So you want to share the generated native code, which at present can even differ between JVM instances, due to different jit options or even different execution patterns.
This is harder than sharing C libs which are native code already - you have to either precompile the shared jars or make the shared library manager understand the intricacies of the java jit compiler.
Re:No raw sockets in XP?
on
Nmap 4.00 Released
·
· Score: 4, Interesting
I wonder what's the logic in disabling raw sockets...
Stupidity + historical reasons, which I am recalling from memory:
1. Microsoft implements raw sockets, with some efforts to restrict access to them - only Administrators can use them.
2. On XP all users are Administrators by default.
3. Some people point this out, the stupidest being the loudest .
("Full Raw Sockets were created as a potent research
tool. They were NEVER INTENDED to be shipped in a
mass-market consumer operating system." )
4. Microsoft thinks it's a good idea.
Those vile practices reinforced the social trend to objectify females. I solemnly applaud the decision to ban them. Now take me to the pictures! What? No pics?!?!?!?
The issue with Perl isn't that it's particularly hard to do complicated things with simple, legible code (not more so than a lot of other languages, anyway), but that it's very, very easy to do something extremely quickly, which often - but not always - means code that makes sense at the time but isn't necessarily readable, or leads to overly terse code.
Well, I am starting to see some of this also in Python. Here are some mini-WTFs I found while maintaining a Python app. Replace the starting dots with spaces, I'm too lazy to figure out how to indent in slashdot-html. And one thing - this isn't to support the thesis that Python, or dynamic languages in general are bad. It's rather to say that you cannot (and should not try) design a language where it's easy to write 'good' things and difficult to write 'bad' things.
My comment - it's reflection being abused + lack of private fields. This, of course isn't python-specific. Yeah, I know of the __privateField convention. Too sad it isn't more widespread. Everytime I see something like this, I get more convinced that 'private by default' should be, ugh... a default;-).
I feel tempted to add a bogus 'proxy' field to the last object in the chain and complain to the author that his code doesn't work:-) Another one:
My comment - Python makes it easy to abuse sequences(tuples,lists) as return values. It starts innocent. You find out that a function returning a value needs to return something more - a source of the value, a condition, whatever. You simply change the return retval to return (retval,condition) and the calling code from a=foo() to a,cond=foo(). This repeats several times, each time making it harder to return (I mean refactor all the code using the function) something more explicit, like a proper object or at least a dictionary of named values. Soon you have to memorize that foo()[6] is status and bar()[7] is timestamp. It gets even worse when you start nesting sequences. Soon you have to write foo()[0][1][0][1][1] , then you replace it with cadaddadr(foo()) functions and become a LISP-er;-P. Again, this is neither python-specific, nor an argument against flexible data structures. I love being able to write [1,'banana', self.aMethod, (1,'dog') ], especially in one-time-run or proof-of-concept code. One just has to remember it can accumulate and fall on your head.
This has gotten long, so I'll just repeat: this is just to show that people will always find ways to write muddy code. Python has still an unbelievable easiness/muddiness ratio:)
Next they'll be asking us to pick lentils from the ashes:-)
Hither, hither, through the sky,
Bearded geeks and fat nerds, fly!
Whether bi or straight or gay,
Hither, hither, haste away!
One and all come help me, quick!
Haste ye, haste ye! - pick, pick, pick!
His research basically is about happiness--it's all any of us really, universally, want, so why, after millions of years of evolution, are we so bad at finding it?
Because the ultimate direction of natural selection is your reproduction, not your happiness. From the evolution point of view the optimal state of the human is probably unhappy enough to get up from ones ass and accumulate some more resources for successful reproduction, but not enough to break down and commit suicide.
The most popular way of getting happiness is probably having a passion and dedicating your life to it. Unless this passion is raising own kids, this is a failure from the evolutionary point of view.
>we didn't have a design document and as such we could not deliver.
That's the biggest of many difficulties pointed out in the interview.
No, the biggest of the difficulties, the root of all the other ones, was a bunch of incompetent jerks in positions of power. To succeed one needs at least competent jerks or incompetent non-jerks (quick def: folks not immune to reason, having a minimum of social skills), although without at least one competent non-jerk, the future is troublesome.
This is almost a tautology - bad decisions make projects fail. To have good decisions, you either have to make them yourself (be competent) or get them from others (be a non-jerk). Being a non-jerk also helps in getting people to implement the decisions.
Speed isn't everything. I prefer a slower disk with a region-free firmware update available over a faster one that lets the MPAA restrict how I use my property.
Slashdot Mirror
Any reason why The Fallacy of Cracking Contests doesn't apply to this one?
And what happens in case of power failure? Or lock failure? Or when the key battery dies?
- no mass updates/deletes.
- no aggregation (count,max,min,sum)
- no dynamic queries
- restricted joins
I've heard they fixed it to some degree in EJB ver. 3.0, getting it close to the actual SQL expression power.
Do you know a persistence framework that doesn't expose SQL and yet gives you the power that SQL does?
I do cross-platform programming with wxWidgets, a library that still lets me access the underlying OS widgets. I get both platform independence and ability to work around an occasional platform-specific wxWidgets kludge. This of course doesn't mean that my app works only on windows.
Singletons in the J2EE framework. Compare this monstrosity with a sigleton implementation in any sane language, including the simple, non-J2EE Java. Mind you, I'm not bashing J2EE here , the singleton issue is the price you pay for scalability.
Using Java for GUI on Windows. Most GUI libraries built on top of the winapi at least let you get the window handle from their widget implementations so that you can get straight through to win32 and do your hacking there (possibly fkcuing up the lib, since it doesn't know about your updates, but that's another issue :) ). This is not the case with Java - if a winapi function is not reflected in the Java API, you are pretty much screwed.
Persistence frameworks. "You won't have to write a single SQL statement for the rest of your life!". But if the statement generated by the framework is suboptimal, then guess what? Yup, screwed again.
Good luck choosing your framework. I hope I scared you to death, because, in my opinion you cannot be too scared of frameworks :)
As to keeping commitment, do you expect the agency to guarantee that the guy doesn't quit? Seriously, it is the employer's and only employer's responsibility to keep the employees employed. You cannot outsource that.
No funds? So you expect someone to do the screening work and give you free access to it online? Keep on dreaming.
dddddddddddddddddddddddddddddddddddddddddddddddddd ddddddddddddddddddddddd
Anything other than that is just anti-consumer bullshit, with weak pseudo-techological excuses.
Giving 100% trust to a company that has a track record of kowtowing to oppressive governments... what can possibly go wrong?
This is harder than sharing C libs which are native code already - you have to either precompile the shared jars or make the shared library manager understand the intricacies of the java jit compiler.
1. Microsoft implements raw sockets, with some efforts to restrict access to them - only Administrators can use them.
2. On XP all users are Administrators by default.
3. Some people point this out, the stupidest being the loudest . ("Full Raw Sockets were created as a potent research tool. They were NEVER INTENDED to be shipped in a mass-market consumer operating system." )
4. Microsoft thinks it's a good idea.
Those vile practices reinforced the social trend to objectify females. I solemnly applaud the decision to ban them. Now take me to the pictures! What? No pics?!?!?!?
This has gotten long, so I'll just repeat: this is just to show that people will always find ways to write muddy code. Python has still an unbelievable easiness/muddiness ratio :)
Just kidding.
Getting free stuff is easy. Not getting caught is the hard part!
Who needs unlimited funding when you have such a sound methodology? :-P
The most popular way of getting happiness is probably having a passion and dedicating your life to it. Unless this passion is raising own kids, this is a failure from the evolutionary point of view.
This is almost a tautology - bad decisions make projects fail. To have good decisions, you either have to make them yourself (be competent) or get them from others (be a non-jerk). Being a non-jerk also helps in getting people to implement the decisions.
Speed isn't everything. I prefer a slower disk with a region-free firmware update available over a faster one that lets the MPAA restrict how I use my property.