Overkill it may be, but I've been writing my prototype security code to generate new AES256 keys for each session, using the pre-generated keys only to initialize communications and handshake the generated keys. Even I won't know what keys are in use.
The NSA can kiss my ass. So can CSEC, GCHQ, and everyone else who thinks they have a "right" to spy on me.
Approach the service provider with a properly signed warrant in the appropriate jurisdiction of the server if you want access to my data.
I've yet to meet a Buddhist who was anything like you describe. Don't confuse Buddhism with Californicatin' "New Age" hipsters. The latter only claim to be Buddhists, and only pick and choose a few select pieces of their scripture that goes with their crystal-worshipping nonsense.
A buddy's brother works (or worked, who knows now) for Intel, and used to bring along demos of the latest and greatest lab technology when he came for visits. Some of the stuff he had was up to 10-15 years ahead of actual release cycles in terms of performance and capability. I'm sure some of the ideas got scrapped, but a lot of them probably made it into production in the chips we use today.
Wild stuff. Both brothers were major hardware geeks.
I'd love to see what kind of technology he's showing his brother from the labs over Christmas and Easter holidays nowadays.:D
What kills all console games eventually is the difficulty of working with their development kits, and the paucity of documentation about how to wring maximum performance out of those development kits.
Write a game using OpenGL or DirectX, and you have millions of potential buyers. Write a game using Android or iOS APIs, and you have millions of portable buyers.
Consoles? Not so much. Your only market with those devices are dedicated gamers willing to spend money just to play games. It's a smaller market share by a huge margin.
No matter what you do in life, you are going to die. There is no escaping that.
So live a life of wonder, mystery, and enjoyment, rather than spending it fretting about exactly what might be the thing that kills you. Eat a bacon sandwich. Put cream in your coffee. Have a steak once in a while. Have a doughnut once a month. And by all means, have a glass of wine with your meal and spark a bowl of cannabis afterwards.
Apparently the issue depends on where you live, because while I used to see such wankers in Regina, Saskatchewan, I've never had the problem in the smaller community of Yorkton. Not only will people both walk through the snowbank on the side of the tromped-down path here, they'll actually say "Hi" to you while you're passing them.
they should be able to expect that junior can sit at the computer and look up something for school and not get links to goatz or tubgirl or whatever
That is absolute nonsense. I have never had Google nor Bing bring up porn when I was searching for terms that didn't involve pornography. This whole concept of "drive by porning" is nothing more than fear, uncertainty, and doubt spread by the "think of the children" namby-pambies who want to block adult sites from anyone accessing them on the internet.
If your kids are finding porn on the internet, it's because they're looking for it. Stop blaming the internet, and start blaming your horny or curious kid.
That "powerful AI" thinking is done by designers and analysts, not programmers. The vast majority of "programmers" merely translate the business models and logic specifications into code. What I'm saying is that we're not far off at all from capturing that information in the business models and diagrams themselves, and translating it directly into code without the intervention of "grunt coders" (the people you hire for $20/hr from sweat shops or through overseas companies.)
Those few who are also business analysts and designers will be working with those new tools instead of UML diagrams. They'll push a button, and bam, out comes most of the code for implementing the system.
User interface programming and report specifications are the only aspect of "programming" that I see as being retained by the human coders in the long run, and even the report specifications could prove subject to analysis algorithms that allow a report designer to simply highlight the model attributes they want to present, drop-down-select group-by functions over those attributes, and do a little bit of layout specification to produce the report. For all I know, there are already tools that let you do that.
You only need "strong AI" if you expect the system to be designed by the system. I'm not expecting any such thing -- I'm merely expecting the automation of grunt work and IDE point-and-click operations by rule-based systems.
If you want a crude example of the kind of technology I'm talking about, check out my pet project, MSS Code Factory. From an XML business application model, it produces the database schema scripts, stored procedures, JDBC layers, object implementations and interfaces, and XML messaging layers. I keep adding to it and extending it, but it does more than enough to prove my point: you can automate an awful lot of the grunt code of a system.
Now if I can automate that much of the coding process by myself, imagine what a team of serious computer scientists with a real budget could do in the bowels of an IBM, Microsoft, or Apple R&D department.
Anything that can be automated will be. An awful lot of programmers are already doing nothing more than running macros and "smart commands" with IDEs like Eclipse to produce the bulk of their code. Given a sufficiently detailed application model and an appropriate rule engine, the need for that "skillset" becomes obsolete.
Eventually only the highest level functions will need to be coded "by hand", themselves driven by the application models instead of class and structure definitions.
Throughout my career as a programmer and even after I retired, programming has consistently and constantly evolved to higher and higher levels of abstraction. It's only a matter of time, effort, and the question of who will be first to market.
I'm pretty sure any power-line noise from a memory card is dwarfed by the poor sound quality of the chip amps used on most portable audio devices.
As to non-portable devices, the noise of case and laptop fans and even the chirp of hard drives seeking drown out any "feedback noise" I get even from the chip amps used in my computers to drive the speakers. While I do spring for low-dB fans whenever I'm replacing them, they still produce an emphatic whoosh in the background no matter how good they are.
Whan I want to really listen to music, I far prefer my Sony noise-cancelling ear-cup headphones to using speakers. Ambient noise in this place is just too high to really enjoy music any other way. And I suspect the same is true of most homes that don't have dedicated sound rooms with thousands of dollars invested in baffling, damping, and so forth.
If you redefine terms on the fly, you can make any argument you want to.
My point was and is that database IO blocking is the issue for at least 90% of real front-line business applications, regardless of whether they are serving internal or external customers. Client-side joins of such data are extremely rare -- there are remote database options for doing that far more efficiently and effectively provided by every major database vendor out there.
If you're doing client-side joins, you aren't using your tools very effectively, and should be fired.
I fail to see the benefit of "non-blocking IO" when it is database concurrency that is the issue for most applications that are used to update information. So what if your first fragment of HTML can be shipped back to the client before you finish processing the page? If your servlets are taking so long to run that network IO blockages are "important to performance", you have some serious problems with your application logic.
I'll be happy to let you scan my computer -- if you show up with a warrant authorizing you to do so. I have nothing to hide; that doesn't mean I'm going to broadcast it and make it easy pickings for your fishing expeditions.
The public is not driving a "demand" for law enforcement to have a way past people's strong encryption. They're driving a navel-gazing demand that everyone else's strong encryption be breakable, but not theirs.
Worse, law enforcement is ignoring the fact that they're supposed to get warrants to access people's information, and are bitching to high hell that people are taking steps to stop their illegal snooping.
Too bad, fuzzballs. You, the NSA, CSEC, GCHQ, and everyone else who thinks their "need" to spy is greater than my need for information security can take a spin on a sharp pole.
The inverse is also true. You have many, many, MANY cases of people being charged with being "impaired" because of metabolites when they weren't at all high. In fact, given the state of current "tests" for "cannabis impairment", I'd say most cases of "impairment" were no such thing.
Practical experience over several years with projects in the 7-12 million line size. Subversion chokes on large projects whether you fanatics like it or not. GIT was *designed* for large projects and does a much better job of handling them.
If you're running Subversion over the internet, it becomes dog slow for large checkins.
Oh, now, come on. If you're just using GIT for the basics, it's a matter of changing the name of the command you're running. It's not "harder" to use than Subversion -- it just has extra features you don't have to use.
Slashdot Mirror
Overkill it may be, but I've been writing my prototype security code to generate new AES256 keys for each session, using the pre-generated keys only to initialize communications and handshake the generated keys. Even I won't know what keys are in use.
The NSA can kiss my ass. So can CSEC, GCHQ, and everyone else who thinks they have a "right" to spy on me.
Approach the service provider with a properly signed warrant in the appropriate jurisdiction of the server if you want access to my data.
You spent 10.4 minutes in the bathroom this morning.
The staff in your department average 5.6 minutes.
The doors in your office will therefore remain locked until 5:04 today to ensure you make up the time.
This was a lot of years ago. Things weren't as tightly controlled back then. '386 days...
I think you underestimate how much of the design is actually done by computers and auto-routing/placement algorithms.
I've yet to meet a Buddhist who was anything like you describe. Don't confuse Buddhism with Californicatin' "New Age" hipsters. The latter only claim to be Buddhists, and only pick and choose a few select pieces of their scripture that goes with their crystal-worshipping nonsense.
A buddy's brother works (or worked, who knows now) for Intel, and used to bring along demos of the latest and greatest lab technology when he came for visits. Some of the stuff he had was up to 10-15 years ahead of actual release cycles in terms of performance and capability. I'm sure some of the ideas got scrapped, but a lot of them probably made it into production in the chips we use today.
Wild stuff. Both brothers were major hardware geeks.
I'd love to see what kind of technology he's showing his brother from the labs over Christmas and Easter holidays nowadays. :D
What kills all console games eventually is the difficulty of working with their development kits, and the paucity of documentation about how to wring maximum performance out of those development kits.
Write a game using OpenGL or DirectX, and you have millions of potential buyers. Write a game using Android or iOS APIs, and you have millions of portable buyers.
Consoles? Not so much. Your only market with those devices are dedicated gamers willing to spend money just to play games. It's a smaller market share by a huge margin.
Somebody beat me to it. :)
No matter what you do in life, you are going to die. There is no escaping that.
So live a life of wonder, mystery, and enjoyment, rather than spending it fretting about exactly what might be the thing that kills you. Eat a bacon sandwich. Put cream in your coffee. Have a steak once in a while. Have a doughnut once a month. And by all means, have a glass of wine with your meal and spark a bowl of cannabis afterwards.
No one ever said it was a documentary. It's a movie meant to entertain, not inform.
Apparently the issue depends on where you live, because while I used to see such wankers in Regina, Saskatchewan, I've never had the problem in the smaller community of Yorkton. Not only will people both walk through the snowbank on the side of the tromped-down path here, they'll actually say "Hi" to you while you're passing them.
That is absolute nonsense. I have never had Google nor Bing bring up porn when I was searching for terms that didn't involve pornography. This whole concept of "drive by porning" is nothing more than fear, uncertainty, and doubt spread by the "think of the children" namby-pambies who want to block adult sites from anyone accessing them on the internet.
If your kids are finding porn on the internet, it's because they're looking for it. Stop blaming the internet, and start blaming your horny or curious kid.
The best trick is for parents to actually supervise their children.
I hate all you lazy buggers who just "plug the kids in" and leave them for hours a day unsupervised. Do your damned job as parents!
That "powerful AI" thinking is done by designers and analysts, not programmers. The vast majority of "programmers" merely translate the business models and logic specifications into code. What I'm saying is that we're not far off at all from capturing that information in the business models and diagrams themselves, and translating it directly into code without the intervention of "grunt coders" (the people you hire for $20/hr from sweat shops or through overseas companies.)
Those few who are also business analysts and designers will be working with those new tools instead of UML diagrams. They'll push a button, and bam, out comes most of the code for implementing the system.
User interface programming and report specifications are the only aspect of "programming" that I see as being retained by the human coders in the long run, and even the report specifications could prove subject to analysis algorithms that allow a report designer to simply highlight the model attributes they want to present, drop-down-select group-by functions over those attributes, and do a little bit of layout specification to produce the report. For all I know, there are already tools that let you do that.
You only need "strong AI" if you expect the system to be designed by the system. I'm not expecting any such thing -- I'm merely expecting the automation of grunt work and IDE point-and-click operations by rule-based systems.
If you want a crude example of the kind of technology I'm talking about, check out my pet project, MSS Code Factory. From an XML business application model, it produces the database schema scripts, stored procedures, JDBC layers, object implementations and interfaces, and XML messaging layers. I keep adding to it and extending it, but it does more than enough to prove my point: you can automate an awful lot of the grunt code of a system.
Now if I can automate that much of the coding process by myself, imagine what a team of serious computer scientists with a real budget could do in the bowels of an IBM, Microsoft, or Apple R&D department.
Anything that can be automated will be. An awful lot of programmers are already doing nothing more than running macros and "smart commands" with IDEs like Eclipse to produce the bulk of their code. Given a sufficiently detailed application model and an appropriate rule engine, the need for that "skillset" becomes obsolete.
Eventually only the highest level functions will need to be coded "by hand", themselves driven by the application models instead of class and structure definitions.
Throughout my career as a programmer and even after I retired, programming has consistently and constantly evolved to higher and higher levels of abstraction. It's only a matter of time, effort, and the question of who will be first to market.
But it will happen.
I'm pretty sure any power-line noise from a memory card is dwarfed by the poor sound quality of the chip amps used on most portable audio devices.
As to non-portable devices, the noise of case and laptop fans and even the chirp of hard drives seeking drown out any "feedback noise" I get even from the chip amps used in my computers to drive the speakers. While I do spring for low-dB fans whenever I'm replacing them, they still produce an emphatic whoosh in the background no matter how good they are.
Whan I want to really listen to music, I far prefer my Sony noise-cancelling ear-cup headphones to using speakers. Ambient noise in this place is just too high to really enjoy music any other way. And I suspect the same is true of most homes that don't have dedicated sound rooms with thousands of dollars invested in baffling, damping, and so forth.
If you redefine terms on the fly, you can make any argument you want to.
My point was and is that database IO blocking is the issue for at least 90% of real front-line business applications, regardless of whether they are serving internal or external customers. Client-side joins of such data are extremely rare -- there are remote database options for doing that far more efficiently and effectively provided by every major database vendor out there.
If you're doing client-side joins, you aren't using your tools very effectively, and should be fired.
I fail to see the benefit of "non-blocking IO" when it is database concurrency that is the issue for most applications that are used to update information. So what if your first fragment of HTML can be shipped back to the client before you finish processing the page? If your servlets are taking so long to run that network IO blockages are "important to performance", you have some serious problems with your application logic.
Closely followed by Java.
I mean, seriously -- how *else* are you supposed to transfer control of your browser to a nefarious third party?
Flash.
I'll be happy to let you scan my computer -- if you show up with a warrant authorizing you to do so. I have nothing to hide; that doesn't mean I'm going to broadcast it and make it easy pickings for your fishing expeditions.
The public is not driving a "demand" for law enforcement to have a way past people's strong encryption. They're driving a navel-gazing demand that everyone else's strong encryption be breakable, but not theirs.
Worse, law enforcement is ignoring the fact that they're supposed to get warrants to access people's information, and are bitching to high hell that people are taking steps to stop their illegal snooping.
Too bad, fuzzballs. You, the NSA, CSEC, GCHQ, and everyone else who thinks their "need" to spy is greater than my need for information security can take a spin on a sharp pole.
The inverse is also true. You have many, many, MANY cases of people being charged with being "impaired" because of metabolites when they weren't at all high. In fact, given the state of current "tests" for "cannabis impairment", I'd say most cases of "impairment" were no such thing.
Practical experience over several years with projects in the 7-12 million line size. Subversion chokes on large projects whether you fanatics like it or not. GIT was *designed* for large projects and does a much better job of handling them.
If you're running Subversion over the internet, it becomes dog slow for large checkins.
Oh, now, come on. If you're just using GIT for the basics, it's a matter of changing the name of the command you're running. It's not "harder" to use than Subversion -- it just has extra features you don't have to use.
GIT also does checkouts/checkins a lot faster than Subversion. Usually 30-40 seconds vs. 20 minutes or more for Subversion.