Seems to me that if everyone used NoScript it would eliminate a lot of cross-site scripting and phishing issues. That alone is enough reason to install and enable it by default on Firefox.
Putting in an outbound firewall that completely blocks access to port 80 also does a good job at stopping all of the cross-site scripting and phishing issues. Enabling NoScript by default is like saying "We want to cripple the average user's Gmail/OWA experience". Javascript disabled-by-default is (unfortunately) not an option for any browser that targets non-nerds.
I do like the idea of bundling it by default. Though, I'd be a fan of Firefox Extension bundles in general, and making extensions powerful enough that the Firefox core becomes a bit more like Eclipse.
Php is not used for large scale sites and it is pretty much hackable though improving. Real sites use java and.NET for ecommerce. But again if its a small business who knows.
Yahoo switched to PHP in 2002, and I wouldn't call it a small website. PHP certainly can scale well, if you know what you're doing and use it the way it was intended (light and fast RAD, compiled extensions for heavy work).
Yes, the PHP core developer community has a bad rap for security (and rightly earned, I believe), but an overwhelmingly large majority of "hackability" is poorly-written PHP applications. Secure PHP is something of a catch-22: security-minded people avoid because of the reputation, leading to a complete lack of security in new development and worsening the reputation. Put a competent developer into any of those languages and the relative differences between Java/.NET/PHP shrink dramatically.
A small minority of programmers do things like write Operating Systems, Protocol Stacks,... These people are well served by CsC degrees, a fondness for algorithms, CPU Arch. knowledge, a current IEEE membership, etc.
Add to that list anything related to scientific/numerical computing. Dynamic meshes for physics simulations, image/video processing, etc.
The gigantic majority of code used in this world is not written by technology companies. It is written by folks working in corporate IT departments... These folks really don't need to spend a great deal of time learning basic principles, because processor architecture really isn't relevant to SQL or LAMP. These folks can get by with a Community College degree where they will either learn to program properly, or not.
Software developers of business applications tend to fall on their faces if they're just "programmers". That, or their applications never get big enough. My interests lie largely on the "softer" side of Computer Science (heavy interest in software engineering/design/architecture and human-computer interactions), but I certainly think a full Computer Science program makes a big difference. Application developers still need to address issues like avoiding deadlocks, transactional safety, algorithms, and efficient data structures.
Maybe in the future the Computer Science degree will be separated from the Software Engineering degree (much the same as Computer Engineering is separate, though sharing similar roots), but for now, a Computer Science degree is still the best place to study effective software development.
Honestly, the structure of a lot of software (likely written by the folks who don't how "basic principles") makes my eyes bleed. Someone with that sort of education and solid domain experience coming into a small company could easily match the productivity of 3-4 run-of-the-mill programmers.
3D rendering/animation creation software
Photoshop, Illustrator, and other image editing/creation software
VirtualDub, Premiere, and other video editing/manipulation software
Protools, Cubase, Cakewalk, tracker software, and other audio/music editing/creation/manipulation software
You just listed a bunch of applications that are very CPU-intensive and "extremely parallelizeable". That is, every single one of those applications would be great to distribute. All modern production-level renderers operate on clusters (renderfarms). Apple's Logic software (similar to Pro Tools) supports distributed processing.
Any digital artist would *love* to have even a small cluster available to do previews... while Maya et al have very good OpenGL previews, there's never enough CPU power for computer graphics (and I believe there never will be).
Computer games
Desktop finance management software
You don't see any benefit of networking these applications? Maybe for a person's own finance management software a network would be overkill, but any company with more than 1 person handling finance management benefits from a remote data store and thick clients. Maybe you always play single player games, but I occasionally play StarCraft with a friend. Across a network.
Are you telling me its easier to build a lean-to than it is to break it down?
No, I'm refuting your comment that it's easier to build bombs than buildings. Destroying something is not the same as creating a device of destruction. Weapons-grade plutonium is harder to acquire than whatever gets used in power plants because the technology has more requirements for success. If it seems easier, it's only because of our unfortunate destructive tendencies.
Suffice it to say it's obviously harder to build a star than a black hole. Like it's easier to build bombs than buildings.
If that were true, I would be living inside of a bomb instead of a building.
...checking...
Nope. Turns out there's way more buildings than bombs in the world. Even if you count something like a maltov cocktail, the flammible liquid is still harder to acquire than a lean-to.
I'm scared that it would be feasible to store logs of URLs visited (at most a few hundred per customer per hour?).
You underestimate the web pages you visit. I did an experiment a few weeks ago along these lines using Firefox's LiveHTTPHeaders. After hitting the front pages of Slashdot, MSN, Yahoo, and two other portal sites, I had 150 requests. That's 30 requests per page. Just now, loading yro.slashdot.org took over 50 requests.
People generate an enormous amount of web traffic without even thinking about it. To expect every ISP to archive that information just because is crazy. It's only really feasible for someone like Google, who is in the business of profiling potential customers (or AT&T, who is in the business of letting the Feds spy on you).
40K pay cut? I do the systems type programming, and make far more than anyone I know doing buisness type systems- they tend to look for bottom of the barrel coders and anyone who took a certification course, where systems level programming requires brains.
There's a lot more work available for the business-type systems, mostly because there's a lot of repetition that goes in (thankfully OSS solutions are reducing that). For stupid business systems you can get away with stupid programmers, and that's what happens because it's cheaper. But you still need brains (or a lot of time and failure) to produce the smarter business systems.
I guarantee you if The People With Money were pushing for systems programmers, you'd see an influx of blub programmers in your field, too.
Well whenever you say "policy" I hear a decision made by a committee, not by a software algorithm, and hence something that is too slow to change if the measurements change.
My intent is a policy made by a few network engineers, as determined by their daily/weekly reports. Too slow to deal with an immediate network need (viral infections on the network), but certainly fast enough to respond to application lifecycles.
As the needs of even a particular web page change, a dynamic scheduler could adapt to give the appropriate priority. There is no way you could assign a static priority to web traffic that would be even close to optimal.
If you have pointers to information about adaptive QoS (maybe using machine learning?), I'd love to see them. It would be great to be able to automate the human policy-decider's job (with the intent that those people would then manage and improve the automation).
I don't buy that argument. He claims that QoS becomes useless when the Internet Pipes are completely full, likening it to emergency vehicles on the road. However, QoS allows packet reording between streams, so there's no notion of "I can't get through because something's obstructing me". QoS really shines at maximum capacity, because the higher capacity results in more prioritizations necessary.
Bricklin's second argument about buying more infrastructure instead of applying QoS is a bit of a tangent, as well. Maybe for a huge company like AT&T there's dark fiber sitting around providing a scarce resource, but all of the ISPs that aren't mega-corporations have to choose between paying big bucks for the bandwidth or applying QoS essentially for free. Besides, there's no reason that a company can't just do both. There's no mutual exclusitivity.
One of the problems I have with this otherwise reasonable concept is I don't like the decision being made on an app by app basis. For one thing, who decides what app gets priority, the ISPs? Second, what if the assumed usage model doesn't match reality, and you have either high bandwidth but high priority apps chewing up all the bandwidth?
(emphasis mine)
No one should be deciding QoS policies based on assumptions. They should be based on measurements. When there is a feedback loop between policy measurement and adjustment, that isn't a problem. Of course it would be a problem if the network engineers were pulling priorities out of their asses, but typically there's some sort of measurement (because every ISP gets bandwidth complaints, and effective QoS makes more people happier).
It would be a problem if there were a high-bandwidth, high priority application. I think Web traffic is the closest example, because it is both sensitive to latency and bandwidth constraints. However, because the latency doesn't garble the web page (the way latency messes with voice traffic), it should probably be prioritized below VoiP. If there were really more VoiP traffic than Web traffic, we'd have a more serious problem, but that's not the reality for most ISPs.
The problem with QoS is that it can be faked, trivially. Unless there's actual packet sniffing being done to identify traffic, which is rarely done (costly), you can simply hide your traffic on a "privileged" port
Linux iptables has a layer7 module that's fairly easy to use and matches common packet types. While it's possible to fake QoS (e.g. XML-RPC is usually embedded inside an HTTP packet, so it would get the same priority as all other web traffic), it's not always as trivial as switching a port.
Furthermore, if you switch your bittorrent onto a VOIP port, some QoS policies will hurt anyways because they limit maximum packet-size for VOIP (specifically to avoid the sort of abuse you mention).
I even remember some people telling me that POST request is more secure than GET since client can see contents of GET request in URL
POST is more secure than GET, but not for that reason. The reason is because POSTed data does not get logged. Imagine a perfectly secure website that accepted credit card numbers. If those numbers were recorded on the server side as "GET/form?card=4111111111111111&exp=0909&cvv=211", then all of that security can be defeated by anyone who can access a logfile.
This is similar to "cookieless session" capability of PHP, to inject "PHPSESSID=092348sdf0923ksjdk" or whatever into forms and hyperlinks, so that GET parameter would save a session. It's bad because it puts sensitive data in the URI.
Yes, I know you can configure servers to log POST data, but it's generally a bad practice (because of the privacy concern) and certainly is not on by default on any web servers I've seen.
"In most cases, SQL Server is right becasue a company has in-house SQL Server Admins and deploying another database platform is a waste on company resources. That would entail another complete platform and maintenance/admin skillset."
Agreed.
"Personally speaking, I've never had any issus with any SQL Server versions in either performance, scaling or security. A well installed, maintained and managed setup will work really well and be considerably cheaper than alternatives such as Oracle. While MySQL may be cheaper, it's not as fully featured as SQL Server."
What about a well installed, maintained, and managed PostgreSQL setup? While I sympathize with your concerns for the client business's needs, you seem to be cheating yourself by missing one of the better alternatives (and yes, it does run on windows).
There's a big difference between composition and music performance, much the same way that there's a difference between coaches/strategists and athletes.
This is, of course, assuming you to mean musician as "performance musician", which you allude to by reference playing an instrument.
He's not performing with a musical instrument. He's creating a composition.
Slashdot Mirror
Putting in an outbound firewall that completely blocks access to port 80 also does a good job at stopping all of the cross-site scripting and phishing issues. Enabling NoScript by default is like saying "We want to cripple the average user's Gmail/OWA experience". Javascript disabled-by-default is (unfortunately) not an option for any browser that targets non-nerds.
I do like the idea of bundling it by default. Though, I'd be a fan of Firefox Extension bundles in general, and making extensions powerful enough that the Firefox core becomes a bit more like Eclipse.
Yahoo switched to PHP in 2002, and I wouldn't call it a small website. PHP certainly can scale well, if you know what you're doing and use it the way it was intended (light and fast RAD, compiled extensions for heavy work).
Yes, the PHP core developer community has a bad rap for security (and rightly earned, I believe), but an overwhelmingly large majority of "hackability" is poorly-written PHP applications. Secure PHP is something of a catch-22: security-minded people avoid because of the reputation, leading to a complete lack of security in new development and worsening the reputation. Put a competent developer into any of those languages and the relative differences between Java/.NET/PHP shrink dramatically.
Add to that list anything related to scientific/numerical computing. Dynamic meshes for physics simulations, image/video processing, etc.
Software developers of business applications tend to fall on their faces if they're just "programmers". That, or their applications never get big enough. My interests lie largely on the "softer" side of Computer Science (heavy interest in software engineering/design/architecture and human-computer interactions), but I certainly think a full Computer Science program makes a big difference. Application developers still need to address issues like avoiding deadlocks, transactional safety, algorithms, and efficient data structures.
Maybe in the future the Computer Science degree will be separated from the Software Engineering degree (much the same as Computer Engineering is separate, though sharing similar roots), but for now, a Computer Science degree is still the best place to study effective software development. Honestly, the structure of a lot of software (likely written by the folks who don't how "basic principles") makes my eyes bleed. Someone with that sort of education and solid domain experience coming into a small company could easily match the productivity of 3-4 run-of-the-mill programmers.
You just listed a bunch of applications that are very CPU-intensive and "extremely parallelizeable". That is, every single one of those applications would be great to distribute. All modern production-level renderers operate on clusters (renderfarms). Apple's Logic software (similar to Pro Tools) supports distributed processing.
Any digital artist would *love* to have even a small cluster available to do previews... while Maya et al have very good OpenGL previews, there's never enough CPU power for computer graphics (and I believe there never will be).
You don't see any benefit of networking these applications? Maybe for a person's own finance management software a network would be overkill, but any company with more than 1 person handling finance management benefits from a remote data store and thick clients. Maybe you always play single player games, but I occasionally play StarCraft with a friend. Across a network.
Network != World Wide Web
No, I'm refuting your comment that it's easier to build bombs than buildings. Destroying something is not the same as creating a device of destruction. Weapons-grade plutonium is harder to acquire than whatever gets used in power plants because the technology has more requirements for success. If it seems easier, it's only because of our unfortunate destructive tendencies.
Actually, the ice-dragon postulate has been proven already, but it's kept secret by the Templar. Didn't you see that part of the DaVinci Code?
If that were true, I would be living inside of a bomb instead of a building.
Nope. Turns out there's way more buildings than bombs in the world. Even if you count something like a maltov cocktail, the flammible liquid is still harder to acquire than a lean-to.
You underestimate the web pages you visit. I did an experiment a few weeks ago along these lines using Firefox's LiveHTTPHeaders. After hitting the front pages of Slashdot, MSN, Yahoo, and two other portal sites, I had 150 requests. That's 30 requests per page. Just now, loading yro.slashdot.org took over 50 requests.
People generate an enormous amount of web traffic without even thinking about it. To expect every ISP to archive that information just because is crazy. It's only really feasible for someone like Google, who is in the business of profiling potential customers (or AT&T, who is in the business of letting the Feds spy on you).
There's a lot more work available for the business-type systems, mostly because there's a lot of repetition that goes in (thankfully OSS solutions are reducing that). For stupid business systems you can get away with stupid programmers, and that's what happens because it's cheaper. But you still need brains (or a lot of time and failure) to produce the smarter business systems.
I guarantee you if The People With Money were pushing for systems programmers, you'd see an influx of blub programmers in your field, too.
My intent is a policy made by a few network engineers, as determined by their daily/weekly reports. Too slow to deal with an immediate network need (viral infections on the network), but certainly fast enough to respond to application lifecycles.
If you have pointers to information about adaptive QoS (maybe using machine learning?), I'd love to see them. It would be great to be able to automate the human policy-decider's job (with the intent that those people would then manage and improve the automation).
I don't buy that argument. He claims that QoS becomes useless when the Internet Pipes are completely full, likening it to emergency vehicles on the road. However, QoS allows packet reording between streams, so there's no notion of "I can't get through because something's obstructing me". QoS really shines at maximum capacity, because the higher capacity results in more prioritizations necessary.
Bricklin's second argument about buying more infrastructure instead of applying QoS is a bit of a tangent, as well. Maybe for a huge company like AT&T there's dark fiber sitting around providing a scarce resource, but all of the ISPs that aren't mega-corporations have to choose between paying big bucks for the bandwidth or applying QoS essentially for free. Besides, there's no reason that a company can't just do both. There's no mutual exclusitivity.
(emphasis mine)
No one should be deciding QoS policies based on assumptions. They should be based on measurements. When there is a feedback loop between policy measurement and adjustment, that isn't a problem. Of course it would be a problem if the network engineers were pulling priorities out of their asses, but typically there's some sort of measurement (because every ISP gets bandwidth complaints, and effective QoS makes more people happier).
It would be a problem if there were a high-bandwidth, high priority application. I think Web traffic is the closest example, because it is both sensitive to latency and bandwidth constraints. However, because the latency doesn't garble the web page (the way latency messes with voice traffic), it should probably be prioritized below VoiP. If there were really more VoiP traffic than Web traffic, we'd have a more serious problem, but that's not the reality for most ISPs.
Linux iptables has a layer7 module that's fairly easy to use and matches common packet types. While it's possible to fake QoS (e.g. XML-RPC is usually embedded inside an HTTP packet, so it would get the same priority as all other web traffic), it's not always as trivial as switching a port.
Furthermore, if you switch your bittorrent onto a VOIP port, some QoS policies will hurt anyways because they limit maximum packet-size for VOIP (specifically to avoid the sort of abuse you mention).
POST is more secure than GET, but not for that reason. The reason is because POSTed data does not get logged. Imagine a perfectly secure website that accepted credit card numbers. If those numbers were recorded on the server side as "GET /form?card=4111111111111111&exp=0909&cvv=211", then all of that security can be defeated by anyone who can access a logfile.
This is similar to "cookieless session" capability of PHP, to inject "PHPSESSID=092348sdf0923ksjdk" or whatever into forms and hyperlinks, so that GET parameter would save a session. It's bad because it puts sensitive data in the URI.
Yes, I know you can configure servers to log POST data, but it's generally a bad practice (because of the privacy concern) and certainly is not on by default on any web servers I've seen.
"In most cases, SQL Server is right becasue a company has in-house SQL Server Admins and deploying another database platform is a waste on company resources. That would entail another complete platform and maintenance/admin skillset."
Agreed.
"Personally speaking, I've never had any issus with any SQL Server versions in either performance, scaling or security. A well installed, maintained and managed setup will work really well and be considerably cheaper than alternatives such as Oracle. While MySQL may be cheaper, it's not as fully featured as SQL Server."
What about a well installed, maintained, and managed PostgreSQL setup? While I sympathize with your concerns for the client business's needs, you seem to be cheating yourself by missing one of the better alternatives (and yes, it does run on windows).
There's a big difference between composition and music performance, much the same way that there's a difference between coaches/strategists and athletes.
This is, of course, assuming you to mean musician as "performance musician", which you allude to by reference playing an instrument.
He's not performing with a musical instrument. He's creating a composition.