I suspect neither the "Head of Engineering" nor anybody he or she manages is actually an engineer with an engineering degree. Seems odd to call a whole department of non-engineers "Engineering". Information Technology seems to be fairly relevant to the roles you described.
The phrase 'IT' is so overused, I'm not sure what it means any more.
It means the same as it ever did, Information Technology, it is intentionally a broad term for an industry. Like "Finance", "Retail", "Automotive", "Medical", etc.
OK, maybe it's an ego thing, but I spent a lot of years in grad school, lots of years getting good at creating software, and lots of years getting good at creating technical products and I don't want the same label as the intern who fixes windoze.
Yes, it's an ego thing; that attitude won't help you earn respect or lead peers. You're no better than an intern starting out fixing computers. In my company there is a distinction between "IT" and "development", who most of the rest of the company considers a bunch of "code monkeys". In a closely related company we partner with, everything is called IT, including development. It's no big deal.
we have to stop referring to all these people as 'IT people' or I'm not going to be able to attract and retain the top-tier talent that is required
I disagree, the best people generally do not have the attitude you do. People who are ego-driven or make a big deal about their title are generally high maintenance under-performers.
Am I just being petty? Should I just forget it? Change it slowly over time?
I think you are being petty and should forget it. If it is a big deal to you then changing it over time is a better idea than confronting the CEO directly about it before you take the job.
Just call them the 'Tech Department' or the 'Engineering Deptartment?'"
I'm not sure I follow here, are you asking a question or suggesting your own answer? Software development is NOT engineering. Just as you are concerned about the overuse of the word "IT", I know many engineers who think the word "engineering" is overused. I suspect none of your advanced degrees are in any form of engineering, and 90% of the people you hire will not be engineers of any sort either.
Unlimited does not mean infinite capacity, nor does it mean they will allow a single user to abuse their resources. Unlimited means there are no artificial limits imposed or quotas that you will hit in the normal course of doing business. If you use up the resources you have purchased (e.g. dedicated server CPU) then that wasn't a "limitation" that was imposed on you; you simply used up the resources you had purchased. When shared servers and bandwidth are the question then yes the definition of unlimited becomes a little more gray, but all the stories of "my account was shut off" is usually attributed to some single significant event or obvious case of abuse.
I'm not saying ISP's shouldn't try to create a more clear definition of what resources they can provide on what account levels, but I am saying that people shouldn't think the word "unlimited" implies infinite resources no matter what. Use common sense.
Chrome supports user scripts, and scripts for all of those things already exist. Check out http://www.adsweep.org/ for one. And it is still "just another browser" like Fx, Opera, IE, etc.
I should probably clarify a bit. I was a hiring manager for many years, and now hiring managers report to me. I'm not suggesting to not engage in the interview and ask questions about job relevant topics as they arrive, I was speaking about asking what generally amount to be HR related questions at the end of the interview (as per original topic) when they "turn it over to you". Hiring managers don't want to sit there and try to remember if the time off for bereavement if your great-uncle who is sick dies next week is 2 days or 3 days, etc.
I read most of the suggested questions above my post on the page and on 70% of them they are not relevant to the job at hand which makes hiring managers roll their eyes, sigh, and try to figure out exactly how needy this employee is going to be and if they're willing to put up with them.
So let me change my statement slightly to: ask only duty-specific questions.
The interview is for them to interview you. There may be an opportunity to reciprocate, but don't - the interviewer just wants to finish the interview at that point. If you ask a bunch of questions you may turn them off or change their minds. If they ask, you can just say "not at this time, thank you."
Learn as much as you can about the company before going on the interview, and then be observant when you go to the interview - pay attention to people in the parking lot, smoking at the doors, how the receptionist is, what people are wearing, etc. but don't ask questions during the interview. If they decide they want to offer you a position, that is the time to go back and ask all of your follow up questions.
Without knowing any details beyond what you described, I would say stay away from Megacorp. It sounds like you weren't actively looking for a buyer and if Megacorp never came along you'd be perfectly happy doing what you're doing. When Megacorp gets involved, it will be very time consuming and when the deal is done things will change for you very significantly. When you say "The money is fair enough" I suspect you're not aware of the potential if you create a solid product and succeed in having regular sales on your own. Unless we're talking about money that you all could retire on, in which case forget everything I said above and go for it, then based on the limited information I would say thanks but no thanks, check back in a few years.
I checked out PublicPatent.org and clicked on the "Random Page" link a few times and it seemed to either go to what looked to be a page of spam for some "aaaoe" organization or a page of Chinese characters. All of the AAAOE.COM spam pages follow the same template with different keywords. There were a few other pages that looked like spam as well, I don't think I came across one legitimate article.
The core answer to "are long URL's wasting bandwidth" is no, they are not. The extra bandwidth used is much less than the general background noise of the Internet. There are so many other things that waste more bandwidth than long URL's that it's not worth spending any time worrying about them. Think server headers ("x-powered-by: asp.net" is really annoying), spam, extra email headers, long email threads where the entire original thread is copied each time, un-optimized graphics on web pages, un-optimized javascript/css/html, un-followed prefetching and DNS prefetching, viruses spreading, port scans, etc. The list goes on and on. Watch a raw firewall log on an active connection for about 5 minutes to see what I mean about "background noise". Long URL's can only go to about 2,000 characters (~2KB) before you start running into compatibility issues (IE), and most "long URL's" are much shorter than that even. This just isn't worth worrying about.
Of course, you can only do this if you know you're under attack, and if your infrastructure is set to autoscale, you probably won't know. Until you receive the bill.
Yes because if you happen to use some sort of auto-scaling system, be it at the cloud level or your own management system, it's very likely that you never thought to put in the same monitoring and alerting systems that you already had on your non-cloud, non-autoscaling systems thus ensuring that you will be blindsided by the scenario you just laid out.
Or, you have more than two brain cells to rub together and you already had all of that in place and just pointed it to the auto-scaling cloud system enabling you to react the same way, except without the downtime in the middle.
I'm pretty sure human body temperature is 98.6 degrees F, not 96. Also I don't see how 12 is any better than 10 in centering a window frame, they both divide by two pretty well.
Honestly I can't believe anybody is even trying to make the case that the imperial system is superior in any way to the metric system. Momentum is the only reason the US isn't on the metric system.
Re:1000 mph speed, 100 gallons per mile efficiency
on
1000-mph Car Planned
·
· Score: 1
There is a separate record for it, google for "fastest wheel driven car". The problem is that it's a bit less interesting because somewhere just north of 400 mph you run out of traction to overcome air resistance. They have plenty of engine power for more speed, but they can't get enough of it to the ground through the wheels. Imagine doing a 400mph power slide.
Yes, you've touched on a few key points about fuel economy that people normally get wrong, and I can add some more explanation.
1) Many people believe fuel economy gets better when you drive slower. The problem is that mathematically, the highest gear is the most efficient gear - e.g., you get more turns of the drive wheels in top gear per turn of the engine. So that means that top efficiency must be in top gear, and if you aren't going fast enough to be in top gear then you're not the most efficient.
2) Next up is drag. There are two primary drag forces - rolling resistance (constant) and air resistance (increases with the square of the speed). In pure theory, the most efficient speed is where the resistance of those two forces is equal (the graph should look something like this), so you have to be going fast enough for air resistance to even be an issue - again not typically the case below say 40 or 50 mph, and as cars get more aerodynamic (coefficient of drag decreases) or get smaller (frontal surface area decreases) that speed goes higher.
3) Lastly, the engine itself has an efficient RPM range. Ideally the engine will be fairly efficient at whatever speed #2 produces, but that may not be the case if you have a really tall overdrive gear - so you may need to go faster to bring the engine to an efficient operating speed.
Maybe, but listening to unencrypted traffic is even easier and more simple to automate, and you don't have to "control" any part of the path, you just have to be a peer on the wire. Larger target, easier to do. And I don't believe your door lock simile is actually representative of what's going on with self-signed SSL. If all traffic on the net were at least self-signed SSL, you completely eliminate the "low hanging fruit" and raise the bar for an attacker, requiring more and more complex tools to setup, more CPU power, etc.
all you are trying to do is make that case that bad rendering, which "differs from the intent of the designer" is ok
Ohh, so close. Take out the word "bad" from that sentence and now you've got it. I think your problem is the "intent of the designer" part, as if the designer only had one intent of how it should look - that's the core problem here. Designers need to understand ALL, or at least most of the ways that their content will be viewed and not make assumptions about the user's environment.
Most web "coders" or "programmers" or even "builders"
OK so you were using some terms a bit unusually. Generally in the industry "designer" implies "graphic" in front of it. If you mean somebody who writes code (yes HTML is code) then developer or programmer will suffice. "Web designer" is really ambiguous, go search Monster.com for "web designer" and a bunch of "graphic designer" positions come up.
However that is not the same as what the designer intended
I'm not even sure this follows on from your previous statement, but again I think this is the primary point where you and I seem to differ. What I'm saying is that a designer, web designer, web programmer, whatever - however many people are involved in the GUI design of a web page, should know that they shouldn't have one specific "intent" of what the page will look like. They should know that it will be viewed on an iPhone as well as in Firefox on multiple OS's with different font support, they should know that people with bad eyes and incorrect monitor color settings will be viewing it, etc. etc. If you design on the web, you must keep these things in mind. When you say things like "what the designer intended" that is where I assumed pixel-level placement because that is the level that many graphic designers want it to be (incorrectly). Then they end up doing dumb things like putting text (sentences, long paragraphs) in a graphic so they can control the font / anti-aliasing, etc. That's bad design and has nothing to do with rendering differences between browsers.
advanced HTML with CSS... are absolutely intended to allow for rigid design implementations.
Let's clarify something here: by "rigid" do you mean "not controllable by the user/browser" (wrong) or "more precise placement of elements, on some browsers configured to allow for that"? Again, what I'm saying is that if you design a page improperly, and somebody zooms the text or has a minimum font size, your "rigid" design will break and it won't be as the designer intended. This is not the fault of a browser / rendering engine, it's bad design.
Thanks for conveniently leaving off half of my one argument, "with pixel-level placement", since Yahoo doesn't do that either. Their site handles different text sizes, mobile browsers, zooming, etc. quite nicely. They don't use multiple abutting images or tight tables that require pixel-level precision. I didn't mean that fixed width layouts implied pixel-level precision on all content within the container, honestly I just wasn't thinking about Yahoo.
If you mean a designer who came from a print background and doesn't actually understand the web, i.e. 90% of the designers out there, then yes you're correct.
Now it's time for your education. Not everybody runs a 17" LCD screen at 1280x1024 with the browser maximized and has good eyes and Flash player [current version] properly installed and Javascript enabled. As stated by one of the parents, the web IS NOT SUPPOSED TO BE pixel-level accurate across all display mechanisms all the time. Incompetent designers don't understand this and try to force the issue, you are correct. But look at any successful website - Amazon, Google, eBay, slashdot, anything - none of them used fixed width layouts with pixel-level placement. They all use free-flowing layouts that work well at different text sizes / zoom levels across multiple browsers at various resolutions. That is the intent of the web. Not to mention getting into the semantic web, but that's a whole other discussion and way beyond 99% of today's designers.
Well there are cases where the standard is slightly lenient in the interpretations, but they still generally provide a recommended method. The only time the recommended method shouldn't be used is for special circumstances like accessibility or small screens or touch-interfaces, etc. But "browsers" meant for use on "computers" should still pretty much use the standards the same way. And for the most part they do, with the one glaring exception.
Correcting my own post, of course I'm assuming the parent meant "tabs in separate processes" rather than "threaded tabs". Hopefully the latter doesn't become common slang for the former.
The only word that suffices to describe Firefox's lack of threaded tabs is "shameful". There is no excuse for a modern browser to not have this,
You do know that there are not currently any stable browsers with threaded tabs, don't you? There are exactly two browsers attempting this that are both in early betas. You speak as if it's been common for years and Fx is way behind the game.
Exactly, I have a dedicated credit card just for bill payments that gets fully paid off each month. It allows the automatic payments to be set up, but acts as a buffer to my bank account in case of an error, plus I get to defer payment for 25 days or whatever. Finally, the credit card I use for this is a cash-back card, so I effectively reduce all of my bills by 1%. Billers that don't support credit card payments I use online banking to send a check. I've been a victim of one of those 38-in-100,000 billing errors, I had a DSL company once withdraw $1,300 instead of $56 because of a "glitch" in their system. If that happened against my bank account it would have been a much larger problem.
OK, we've at least dispensed with your 4k stacks argument.
What do you believe to be broken about nspluginwrapper? While there may be some quirks remaining, they recently released their first stable version.
"Secure environment" and "hardened system" are awfully broad terms. Are you using SE Linux/Bastille Linux/App Armor/Exec Shield/Grsecurity/PaX/etc? There are many ways/techniques to secure Linux systems, and while some of them may be difficult to setup or annoying to use, I assure you it is possible to run it and still "be secure", by whatever definition you're using.
Also Adobe doesn't make 64 bit Flash player for *Windows* (XP/Vista), so that is hardly a "Flash Player on Linux" specific problem. People have the same problems with crashes you mention anytime they run 32 bit browsers in 64 bit OS's.
I'm not trying to "get anywhere"; as you said my system works fine. I'm just trying to help you and others. But you seem to think that you already know better than anybody else in which case you're correct, there is no point in further discussion.
Huh? What architecture specifically are you having trouble getting flash to work with? 4k stacks have been on many "stock kernels" for at least three years now. And what security issues are you worried about specific to Flash that don't affect your browser as well?
See my previous post - your computer is broken in some other way. All of these things are perfectly feasible and have been for some time with Flash 9 on Linux. Why don't you post some details of what you can't figure out and we'll see if we can help you here.
Current versions of Flash have worked fine on Linux for well over a year. If you're still having trouble, your computer is broken in some other way that is affecting Flash.
Slashdot Mirror
Engineering is a more term incorrect than IT for a development team. Software development is NOT engineering. Check out these related posts:
#30261998
#30265218
#30261570
I suspect neither the "Head of Engineering" nor anybody he or she manages is actually an engineer with an engineering degree. Seems odd to call a whole department of non-engineers "Engineering". Information Technology seems to be fairly relevant to the roles you described.
The phrase 'IT' is so overused, I'm not sure what it means any more.
It means the same as it ever did, Information Technology, it is intentionally a broad term for an industry. Like "Finance", "Retail", "Automotive", "Medical", etc.
OK, maybe it's an ego thing, but I spent a lot of years in grad school, lots of years getting good at creating software, and lots of years getting good at creating technical products and I don't want the same label as the intern who fixes windoze.
Yes, it's an ego thing; that attitude won't help you earn respect or lead peers. You're no better than an intern starting out fixing computers. In my company there is a distinction between "IT" and "development", who most of the rest of the company considers a bunch of "code monkeys". In a closely related company we partner with, everything is called IT, including development. It's no big deal.
we have to stop referring to all these people as 'IT people' or I'm not going to be able to attract and retain the top-tier talent that is required
I disagree, the best people generally do not have the attitude you do. People who are ego-driven or make a big deal about their title are generally high maintenance under-performers.
Am I just being petty? Should I just forget it? Change it slowly over time?
I think you are being petty and should forget it. If it is a big deal to you then changing it over time is a better idea than confronting the CEO directly about it before you take the job.
Just call them the 'Tech Department' or the 'Engineering Deptartment?'"
I'm not sure I follow here, are you asking a question or suggesting your own answer? Software development is NOT engineering. Just as you are concerned about the overuse of the word "IT", I know many engineers who think the word "engineering" is overused. I suspect none of your advanced degrees are in any form of engineering, and 90% of the people you hire will not be engineers of any sort either.
Unlimited does not mean infinite capacity, nor does it mean they will allow a single user to abuse their resources. Unlimited means there are no artificial limits imposed or quotas that you will hit in the normal course of doing business. If you use up the resources you have purchased (e.g. dedicated server CPU) then that wasn't a "limitation" that was imposed on you; you simply used up the resources you had purchased. When shared servers and bandwidth are the question then yes the definition of unlimited becomes a little more gray, but all the stories of "my account was shut off" is usually attributed to some single significant event or obvious case of abuse.
I'm not saying ISP's shouldn't try to create a more clear definition of what resources they can provide on what account levels, but I am saying that people shouldn't think the word "unlimited" implies infinite resources no matter what. Use common sense.
Chrome supports user scripts, and scripts for all of those things already exist. Check out http://www.adsweep.org/ for one. And it is still "just another browser" like Fx, Opera, IE, etc.
I should probably clarify a bit. I was a hiring manager for many years, and now hiring managers report to me. I'm not suggesting to not engage in the interview and ask questions about job relevant topics as they arrive, I was speaking about asking what generally amount to be HR related questions at the end of the interview (as per original topic) when they "turn it over to you". Hiring managers don't want to sit there and try to remember if the time off for bereavement if your great-uncle who is sick dies next week is 2 days or 3 days, etc.
I read most of the suggested questions above my post on the page and on 70% of them they are not relevant to the job at hand which makes hiring managers roll their eyes, sigh, and try to figure out exactly how needy this employee is going to be and if they're willing to put up with them. So let me change my statement slightly to: ask only duty-specific questions.
The interview is for them to interview you. There may be an opportunity to reciprocate, but don't - the interviewer just wants to finish the interview at that point. If you ask a bunch of questions you may turn them off or change their minds. If they ask, you can just say "not at this time, thank you."
Learn as much as you can about the company before going on the interview, and then be observant when you go to the interview - pay attention to people in the parking lot, smoking at the doors, how the receptionist is, what people are wearing, etc. but don't ask questions during the interview. If they decide they want to offer you a position, that is the time to go back and ask all of your follow up questions.
Without knowing any details beyond what you described, I would say stay away from Megacorp. It sounds like you weren't actively looking for a buyer and if Megacorp never came along you'd be perfectly happy doing what you're doing. When Megacorp gets involved, it will be very time consuming and when the deal is done things will change for you very significantly. When you say "The money is fair enough" I suspect you're not aware of the potential if you create a solid product and succeed in having regular sales on your own. Unless we're talking about money that you all could retire on, in which case forget everything I said above and go for it, then based on the limited information I would say thanks but no thanks, check back in a few years.
I checked out PublicPatent.org and clicked on the "Random Page" link a few times and it seemed to either go to what looked to be a page of spam for some "aaaoe" organization or a page of Chinese characters. All of the AAAOE.COM spam pages follow the same template with different keywords. There were a few other pages that looked like spam as well, I don't think I came across one legitimate article.
The core answer to "are long URL's wasting bandwidth" is no, they are not. The extra bandwidth used is much less than the general background noise of the Internet. There are so many other things that waste more bandwidth than long URL's that it's not worth spending any time worrying about them. Think server headers ("x-powered-by: asp.net" is really annoying), spam, extra email headers, long email threads where the entire original thread is copied each time, un-optimized graphics on web pages, un-optimized javascript/css/html, un-followed prefetching and DNS prefetching, viruses spreading, port scans, etc. The list goes on and on. Watch a raw firewall log on an active connection for about 5 minutes to see what I mean about "background noise". Long URL's can only go to about 2,000 characters (~2KB) before you start running into compatibility issues (IE), and most "long URL's" are much shorter than that even. This just isn't worth worrying about.
Of course, you can only do this if you know you're under attack, and if your infrastructure is set to autoscale, you probably won't know. Until you receive the bill.
Yes because if you happen to use some sort of auto-scaling system, be it at the cloud level or your own management system, it's very likely that you never thought to put in the same monitoring and alerting systems that you already had on your non-cloud, non-autoscaling systems thus ensuring that you will be blindsided by the scenario you just laid out.
Or, you have more than two brain cells to rub together and you already had all of that in place and just pointed it to the auto-scaling cloud system enabling you to react the same way, except without the downtime in the middle.
I'm pretty sure human body temperature is 98.6 degrees F, not 96. Also I don't see how 12 is any better than 10 in centering a window frame, they both divide by two pretty well.
Honestly I can't believe anybody is even trying to make the case that the imperial system is superior in any way to the metric system. Momentum is the only reason the US isn't on the metric system.
There is a separate record for it, google for "fastest wheel driven car". The problem is that it's a bit less interesting because somewhere just north of 400 mph you run out of traction to overcome air resistance. They have plenty of engine power for more speed, but they can't get enough of it to the ground through the wheels. Imagine doing a 400mph power slide.
Yes, you've touched on a few key points about fuel economy that people normally get wrong, and I can add some more explanation.
1) Many people believe fuel economy gets better when you drive slower. The problem is that mathematically, the highest gear is the most efficient gear - e.g., you get more turns of the drive wheels in top gear per turn of the engine. So that means that top efficiency must be in top gear, and if you aren't going fast enough to be in top gear then you're not the most efficient.
2) Next up is drag. There are two primary drag forces - rolling resistance (constant) and air resistance (increases with the square of the speed). In pure theory, the most efficient speed is where the resistance of those two forces is equal (the graph should look something like this), so you have to be going fast enough for air resistance to even be an issue - again not typically the case below say 40 or 50 mph, and as cars get more aerodynamic (coefficient of drag decreases) or get smaller (frontal surface area decreases) that speed goes higher.
3) Lastly, the engine itself has an efficient RPM range. Ideally the engine will be fairly efficient at whatever speed #2 produces, but that may not be the case if you have a really tall overdrive gear - so you may need to go faster to bring the engine to an efficient operating speed.
Maybe, but listening to unencrypted traffic is even easier and more simple to automate, and you don't have to "control" any part of the path, you just have to be a peer on the wire. Larger target, easier to do. And I don't believe your door lock simile is actually representative of what's going on with self-signed SSL. If all traffic on the net were at least self-signed SSL, you completely eliminate the "low hanging fruit" and raise the bar for an attacker, requiring more and more complex tools to setup, more CPU power, etc.
all you are trying to do is make that case that bad rendering, which "differs from the intent of the designer" is ok
Ohh, so close. Take out the word "bad" from that sentence and now you've got it. I think your problem is the "intent of the designer" part, as if the designer only had one intent of how it should look - that's the core problem here. Designers need to understand ALL, or at least most of the ways that their content will be viewed and not make assumptions about the user's environment.
Most web "coders" or "programmers" or even "builders"
OK so you were using some terms a bit unusually. Generally in the industry "designer" implies "graphic" in front of it. If you mean somebody who writes code (yes HTML is code) then developer or programmer will suffice. "Web designer" is really ambiguous, go search Monster.com for "web designer" and a bunch of "graphic designer" positions come up.
However that is not the same as what the designer intended
I'm not even sure this follows on from your previous statement, but again I think this is the primary point where you and I seem to differ. What I'm saying is that a designer, web designer, web programmer, whatever - however many people are involved in the GUI design of a web page, should know that they shouldn't have one specific "intent" of what the page will look like. They should know that it will be viewed on an iPhone as well as in Firefox on multiple OS's with different font support, they should know that people with bad eyes and incorrect monitor color settings will be viewing it, etc. etc. If you design on the web, you must keep these things in mind. When you say things like "what the designer intended" that is where I assumed pixel-level placement because that is the level that many graphic designers want it to be (incorrectly). Then they end up doing dumb things like putting text (sentences, long paragraphs) in a graphic so they can control the font / anti-aliasing, etc. That's bad design and has nothing to do with rendering differences between browsers.
advanced HTML with CSS ... are absolutely intended to allow for rigid design implementations.
Let's clarify something here: by "rigid" do you mean "not controllable by the user/browser" (wrong) or "more precise placement of elements, on some browsers configured to allow for that"? Again, what I'm saying is that if you design a page improperly, and somebody zooms the text or has a minimum font size, your "rigid" design will break and it won't be as the designer intended. This is not the fault of a browser / rendering engine, it's bad design.
Thanks for conveniently leaving off half of my one argument, "with pixel-level placement", since Yahoo doesn't do that either. Their site handles different text sizes, mobile browsers, zooming, etc. quite nicely. They don't use multiple abutting images or tight tables that require pixel-level precision. I didn't mean that fixed width layouts implied pixel-level precision on all content within the container, honestly I just wasn't thinking about Yahoo.
Speak to a designer and you'll see.
If you mean a designer who came from a print background and doesn't actually understand the web, i.e. 90% of the designers out there, then yes you're correct.
Now it's time for your education. Not everybody runs a 17" LCD screen at 1280x1024 with the browser maximized and has good eyes and Flash player [current version] properly installed and Javascript enabled. As stated by one of the parents, the web IS NOT SUPPOSED TO BE pixel-level accurate across all display mechanisms all the time. Incompetent designers don't understand this and try to force the issue, you are correct. But look at any successful website - Amazon, Google, eBay, slashdot, anything - none of them used fixed width layouts with pixel-level placement. They all use free-flowing layouts that work well at different text sizes / zoom levels across multiple browsers at various resolutions. That is the intent of the web. Not to mention getting into the semantic web, but that's a whole other discussion and way beyond 99% of today's designers.
Well there are cases where the standard is slightly lenient in the interpretations, but they still generally provide a recommended method. The only time the recommended method shouldn't be used is for special circumstances like accessibility or small screens or touch-interfaces, etc. But "browsers" meant for use on "computers" should still pretty much use the standards the same way. And for the most part they do, with the one glaring exception.
Correcting my own post, of course I'm assuming the parent meant "tabs in separate processes" rather than "threaded tabs". Hopefully the latter doesn't become common slang for the former.
The only word that suffices to describe Firefox's lack of threaded tabs is "shameful". There is no excuse for a modern browser to not have this,
You do know that there are not currently any stable browsers with threaded tabs, don't you? There are exactly two browsers attempting this that are both in early betas. You speak as if it's been common for years and Fx is way behind the game.
Exactly, I have a dedicated credit card just for bill payments that gets fully paid off each month. It allows the automatic payments to be set up, but acts as a buffer to my bank account in case of an error, plus I get to defer payment for 25 days or whatever. Finally, the credit card I use for this is a cash-back card, so I effectively reduce all of my bills by 1%. Billers that don't support credit card payments I use online banking to send a check. I've been a victim of one of those 38-in-100,000 billing errors, I had a DSL company once withdraw $1,300 instead of $56 because of a "glitch" in their system. If that happened against my bank account it would have been a much larger problem.
I wonder what will happen if they find the cancer warning labels can cause cancer.
OK, we've at least dispensed with your 4k stacks argument.
What do you believe to be broken about nspluginwrapper? While there may be some quirks remaining, they recently released their first stable version.
"Secure environment" and "hardened system" are awfully broad terms. Are you using SE Linux/Bastille Linux/App Armor/Exec Shield/Grsecurity/PaX/etc? There are many ways/techniques to secure Linux systems, and while some of them may be difficult to setup or annoying to use, I assure you it is possible to run it and still "be secure", by whatever definition you're using.
Also Adobe doesn't make 64 bit Flash player for *Windows* (XP/Vista), so that is hardly a "Flash Player on Linux" specific problem. People have the same problems with crashes you mention anytime they run 32 bit browsers in 64 bit OS's.
I'm not trying to "get anywhere"; as you said my system works fine. I'm just trying to help you and others. But you seem to think that you already know better than anybody else in which case you're correct, there is no point in further discussion.
Huh? What architecture specifically are you having trouble getting flash to work with? 4k stacks have been on many "stock kernels" for at least three years now. And what security issues are you worried about specific to Flash that don't affect your browser as well?
See my previous post - your computer is broken in some other way. All of these things are perfectly feasible and have been for some time with Flash 9 on Linux. Why don't you post some details of what you can't figure out and we'll see if we can help you here.
Current versions of Flash have worked fine on Linux for well over a year. If you're still having trouble, your computer is broken in some other way that is affecting Flash.