That's interesting. I can't quite decide if it's useful or goofy. Maybe both. I've done something similar when it makes sense - very recently in fact.
Once I saw this program, with a whole company based on the program, which accepts absolutely anything as free-form text input, or even voice and pictures. If the input resembles a mathematical expression it returns the result of evaluating the expression. Even math with words like "5 grams in ounces". If you give it a picture as input, it returns similar pictures. If you give it input that resembles an address, it returns a map to that address. This strange program, called Google, has been moderately successful.
Extending your idea a bit, rather than copy-pasting those lines, one could have it as a function get_arg_objects(). Yes, it would be a very short function. The Linux kernel uses very short functions like that, and Linux is a tad successful. In fact, many C, perhaps most, programs use one-line functions like that - they call them macros.
Your code reminds me of a strange function in Perl called wantarray(). It allows your function to return different types, depending on that the caller seems to want. So you can easily handle of these appropriately: My_number = foo(bar); My_array_numbers = foo(bar); foo(bar);
That's funny; as I wrote that it didn't occur to me we used to have physical devices called pagers, though they were actually pagees (they got paged). I was thinking of thr monitoring systems that page people.
As you said, the common way of getting software requirements doesn't work too well, and certainly doesn't work *reliably*.
I have a book from the 1970s that describes many of the programs I use every week. They still serve the requirements 40 years later. I'll come back to that set of programs, and how they predicted requirements 40 years down the road, at the end of my post.
Before getting to the 40 year old programs that are still used daily around the world, this topic reminds me of one of the best software design tips that I've been taught. In retrospect it seems obvious, but many programmers haven't thought to do it, and most don't insist on doing it.
90% of the time, you're writing software to better do something that's currently being done some other way. Perhaps you're replacing legacy software, perhaps it's currently being done "manually", people entering data one item at a time. Perhaps you're replacing a paper-based system. Most of the time, you're replacing *some* method of doing the same task.
It logically follows, then, that to fully understand the process, it's requirements and idiosyncrasies, you can watch the people actually doing it. Even better, have them show you how they do it, then try to do the job yourself while they watch and correct you or point out things to be careful of. Take notes during this. Most likely, the way they are using the old system is NOT how it was designed to be used, because the designers of the old system weren't clear on the requirements. But users find a way of meeting their requirements. Watching how they do that shows you what they actually need to get their job done.
Already just by watching them do the task you'll understand the requirements far better than you would by having a meeting with their boss's boss (the common, bad, way to get requirements). After watching them do the task, next ask them two questions:
What about the current process or tools is frustrating for you, or slows you down?
Pretending *anything* is possible, what would your impossible wishes be for this?
The second question often elicits ideas that allow the programmer to say "I can do that, that's easy". Then you begin to glow with heavenly lights because they thought their wish couldn't possibly be granted. Truly, I've done EASY programming tasks that have garnered me a reputation for being able to do the impossible, simply by asking the users what impossible features they wish I could provide. Their conception of what's easy and what's impossible is totally unrelated to what a good programmer can actually do. (You've probably noticed users often think it should be easy for us to do something that's actually nearly impossible. The flip side of that same ignorance is that they think we can't do stuff that we can actually do pretty easily.)
I didn't come up with any of this myself, these aren't my genius ideas and I wouldn't expect anyone else to think of these things. These are things I've been taught along the way, and I wouldn't expect another programmer to think of them, until they are also taught these ideas.
One more thought, or set of thoughts about foreseeing requirements. I was also taught that you can, fairly easily, plan for and program for future requirements without knowing what those future requirements will be. There are two major ways of doing that, both closely related. One is to avoid hardcoding unnecessary limitations. As an example, configuration for my software never has the user provide a configuration value. Instead, each configuration item is a LIST. If my software can send email notifications, it isn't configured with an email address to send to, it's configured with a list of email addreses. If it can read from a data file, it can read from a list of data files, etc. In the code, the added flexibility requires just this additional code: foreach { } That's it. Just "foreach" whenever a configured value is used makes the whole system far more flexible. This is an example of not ar
> For programming skill, I'm going to suggest Zero Bugs and Program Faster
I second that, good book. Specifically it's a collection of good ideas, each of which takes about ten minutes to read. Zero Bugs and Program Faster would be an excellent choice if you want to spend just a few minutes each day, to have continuous slow improvement. It was my bathroom reading for a while and it was perfect for that.
(If you assembled the top 50 best forum posts related to creating robust software, you'd end up with something like this book - about 50 seperate good ideas that are only loosely related.)
Another way to use that book would be to read the same short section each day for a week, so by the end of the week the idea has found a permanent home in your brain.
> You see, I like to have my clocks all reading the same time, so almost all the clocks in my house are atomic clocks and keep themselves sync'ed with WWV.
Your radio synchronized clocks* are accurate to within a about 200ms or so. Using NTP, your clocks can all read the same time to within about 1ms. Any computer or computing device (such as even a consumer grade wireless router) includes a NTP client. You set one device as the master for your house. It syncs to a couple of nearby tier 2 servers, then all your other clocks sync to the local master, which is only nanoseconds away. That can be far more accurate than syncing to a source a thousand miles away, over a 60Khz radio signal.
* Unless you spent at least $1,500 on each clock, what's advertised as an "atomic clock" is actually a radio synchronized clock. Internally it keeps time with a quartz crystal, just like any clock you'd find at the dollar store. However once or twice per day it tries to sync to the radio signal which is loosely synchronized to an actual atomic clock. Operating at only 60Khz, the WWV is significantly less accurate than something like the signals CDMA and GSM phones use.
> Teach them to have pride in their work, and do things well or not do them
With just three hours, if it's not three hours every month, I think this is on the right track. In limited time, you may get the best bang for the buck teaching them how (and why!) to learn rather than teaching technical details.
You can present things like code review (peer review) and automated tools that look for code smells. The dangers of stackoverflow.com and how to know which answers are good.
First, however, you need the WHY. Why should they write better code? Why should they care? I'm known for pointing out how much time and energy we spend "putting out fires" and suggesting instead that we fireproof things up front. I'm all about avoiding having pagers go off on the weekend.
People do things because a) they want to and b) they can. If you just present a skill or tool, they *can* use it, but they won't unless they *want* to. What pain they currently experience can be relieved by following your suggestions?
I also like to save my work locally. I don't like to do everything via the cloud. Let's be specific about what that means:
The cloud: The real work of the application is done on some company's servers. Your machine is only the UI.
Web Assembly and asm.js (and C, C#, Swift etc): The application runs on your local computer. The whole thing is on your computer, not just the UI.
Javascript is rather slow (thousands of times slower than C), so you don't do video editing in Javascript, Javascript sends your data off to some server that does the actual work. C, C#, Swift, and Web Assembly are fast, so they can do video editing locally, without sending anything to any server.
In C, C#, Swift, or Web Assembly you *could* write an application to send the completed output to Dropbox or Google Drive, but there is no need to do that. You can save your work locally if you want to.
The only required difference between the traditional applications you're accustomed to and Web Assembly applications is that Web Assembly applications don't have to be installed. Both do the work locally, and can save the work locally - even on a device with no network connection. Obviously to get the application in the first place, any application, you need either a network correction, a USB stick, or some other way of getting the code to your computer.
> Can you give an example what you mean by belt and suspenders approach?
Essentially I mean wrapping one algorithm within another, such that cracking it requires cracking BOTH algorithms.
I don't know which algorithms we'll be using 10 years from now, but for sake of illustration let's pretend it's good old Diffie-Hellman. For the moment, we'll pretend we think DH is quantum resistant. With DH, each party sends their modulus in the clear. Because you can't solve the discrete logarithm problem, knowing the modulus doesn't let you compute the key. Suppose, however, that a clever person might figure out how to use quantum computers to solve the discrete logarithm and therefore crack DH (we're pretending we didn't expect that). What we can do is instead of sending the modulus in the clear, send it via some other algorithm Y() from an unrelated family. In that way, if the attacker cracks DH generally, that does them no good because the essential part of the DH exchange is invisible to them, protected by Y(). Cracking Y(), it does them no good - that only gets them the computed modulus that was originally intended to be sent in the clear anyway.
Another approach that does basically the same thing would be: 1) Use asymmetric algorithm A() to compute symmetric key ka, as normal.
2) Use asymmetric algorithm B() to compute symmetric key ba, as normal.
3) Use ka xor kb as the actual symmetric key.
Once again the attacker can succeed only by cracking both algorithms A() *and* B().
One should be cautious when combining algorithms; in some cases the combination is weaker than either algorithm alone. For example, md5(sha1(plain)) is weaker than either md5(plain) or sha1(plain). One shouldn't combine algorithms willy-nilly without understanding the consequences, but if done carefully you can guarantee that the combination is stronger than either algorithm alone. (For example, concatenating sha1(plain) with md5(plain) is stronger than either sha1 or md5 - but also results in a hash much longer than either algorithm does alone.)
Of course, it would also be a mistake to combine two *related* algorithms. XORing keys exchanged by two algorithms which both provably depend on discrete logarithm doesn't make it much stronger - if they can solve discrete log, they can crack both algorithms. One would need to combine two unrelated algorithms which depend on different hard peoblems as their primitives.
In case you're wondering, yes, I do security for a living.:)
> Can you give an example what you mean by belt and suspenders approach?
Essentially I mean wrapping one algorithm within another, such that cracking it requires cracking BOTH algorithms.
I don't know which algorithms we'll be using 10 years from now, but for sake of illustration let's pretend it's good old Diffie-Hellman. For the moment, we'll pretend we think DH is quantum resistant. With DH, each party sends their modulus in the clear. Because you can't solve the discrete logarithm problem, knowing the modulus doesn't let you compute the key. Suppose, however, that a clever person might figure out how to use quantum computers to solve the discrete logarithm and therefore crack DH (we're pretending we didn't expect that). What we can do is instead of sending the modulus in the clear, send it via some other algorithm Y() from an unrelated family. In that way, if the attacker cracks DH generally, that does them no good because the essential part of the DH exchange is invisible to them, protected by Y(). Cracking Y(), it does them no good - that only gets them the computed modulus that was originally intended to be sent in the clear anyway.
Another approach that does basically the same thing would be: 1) Use asymmetric algorithm A() to compute symmetric key ka, as normal.
2) Use asymmetric algorithm B() to compute symmetric key ba, as normal.
3) Use ka xor kb as the actual symmetric key.
Once again the attacker can succeed only by cracking both algorithms A() *and* B().
One should be cautious when combining algorithms; in some cases the combination is weaker than either algorithm alone. For example, md5(sha1(plain)) is weaker than either md5(plain) or sha1(plain). One shouldn't combine algorithms willy-nilly without understanding the consequences, but if done carefully you can guarantee that the combination is stronger than either algorithm alone. (For example, concatenating sha1(plain) with md5(plain) is stronger than either sha1 or md5 - but also results in a hash much longer than either algorithm does alone.)
Yeah that statement from the SEC is ridiculous. There's never been any hint of fraud around any Bitcoin exchange. Okay maybe a couple of small exchanges have had issues, but never the big exchanges that handle 3/4 of all Bitcoin transactions, like Mt Gox. There could never be any fraud at Mt Gox.
Yes, it's now slightly less stinky than something that resembles moldy coffee grounds left in the coffee maker over the holidays, or Balmer's ass hole.
It seems all programming languages suck. C, after decades of careful revision, is well suited to certain tasks, but not the tasks that most of us do most of the time.
> Presume it takes 20 days to transport the batteries and maybe another 30-40 to build them all (probably optimistic), they would be left with maybe a month to design, install and test the whole thing.
So you would build it and deliver it, THEN start designing it? A Scrum advocate I'm guessing.
> I wonder whether being behind load balanced proxy servers might have anything to do with it. Anyone else having similar problems?
Yes, proxies correlate well to bots. Not all attempts from proxies are bots, but most attempts from bots come through proxies. Open proxies especially. Open proxies are bad anyway, so make sure your proxies aren't open. If possible, use a firewall to limit access to your proxies by IP address.
In 1999 the Apache Foundation got Tomcat, given to them by Sun. That may have been Apache's first project other than httpd.
What annoys me is that people I work with call all of the 50 or so different projects "Apache", without further specification. I'm well-versed in the Apache httpd code, I've contributed patches and I know configuration tricks and such. So when someone says "I'm having trouble with Apache" I go over to help, only to discover they're working on some Java thing.
GSM data is sent in 156-bit (18 byte) frames, which are then combined into superframes. So anyway the prioritization decision is made every few bytes - millions of times for one video. It needs to be fast, very fast, and a flag indicating "high" or "low" priority is fast - much much faster than computing and comparing a numerical score for each frame to see who is highest, then multiplying the reciprocal of that by time in queue.
Also, long before T-Mobile started prioritizing based on usage so far in month, network protocols and network equipment was built built with traffic classes, not traffic scores. T-Mobile is using pre-existing functionality. It's arguable which provides a "better" customer experience, so they might as well use the simple, efficient, pre-existing method.
We may be talking about two different things. Obviously you can pump water into a paper cup, or a swimming pool or whatever. Let's define exactly what we're discussing.
> We are not talking about CAPACITY. > We are talking about weather or not you need a Hoover Dam like plant design.
Well I said if you want to power a building, you can use any of many designs. If you want to power cities, I said, you're looking at basically a hydroelectric dam type of design. So yes what I said is all about capacity - the capacity to power a city or country, as opposed to a building. Let's get a bit more specific...
The suggestion was: >>>> Take the excess energy generated and pump the water up, then release it through a turbine when your solar farm lacks sun
Okay so we're talking about what you need to do when the solar-electric plant isn't getting much sun. Note it doesn't say anything about load, it says "when your solar farm lacks sun". We'd like for solar-electric to supply a significant portion of our energy needs. Perhaps 25% would be good, that would be equal to 100% of our current *electricity* consumption.
Looking at the current weather forecast, Germany will be covered in clouds Monday, Tuesday, and Wednesday, meaning they'll have minimal solar power power generation for three days. A couple times each year, most or all of Europe is covered by a large storm system for four or five days. So if you're going to be dependent on solar for a significant portion of your daily energy, you're going to need to store enough to power Europe for a two to three days (which will stretch to four or five days because you still get *some* generation despite the cloudy weather).
So that's what *I'm* talking about, what you need in order to make it safe to rely on solar electric as a primary source of energy. You need the capacity to provide millions of people will their energy needs for several cloudy days in a row. You don't get there with 70,000 gallon towers, or 200,000 gallon ponds. To make solar-electric reliably power major cities, you need reservoirs that are hundreds or thousands of square kilometers each, and not just one or two of them, but many, many of them.
>> Might I suggest you read the stories rather than just look at the pictures > Nope, the point of the stories are precisely the pictures
Well, if you don't care to read even the sources you cite, I don't suppose I can help you. Intentional ignorance is permanent ignorance. They do, however, say that you're wrong by orders of magnitude.
>> Enough to charge 20 Teslas > how you come to the idiotic idea that one of the reservoirs would only charge 5 Teslas is beyond me.
You're not lying, you *really* hate to read, don't you.
Storage capacity required to charge just ONE car, as an example load: 90Kwh So the total storage capacity of the entire country could, as example, charge half a million cars and do nothing else - no lights, no cooking, no hot water - in a country with 80 million people. As long as you're happy to share your car 160 other people, and use no other energy for anything else, you've got enough storage.
Might I suggest you read the stories rather than just look at the pictures. One of the stories you linked to points out that a "fact" you stated is wrong by orders of magnitude.
In the stories you linked to, you'll also find the capacities of those reservoirs which consist of a dam all the way around - enough to charge 20 Teslas. Germany has 80 million people. Do you think they're going to build a million or so such reservoirs?
> A hydro pumped storage plant is not the same thing as a hydro dam. Facepalm.
Actually that's *exactly* what it is, unless you're planning on powering one building, in low-power mode, for a few hours. (That you can do with a tower - power the emergency lights in a work building overnight when nobody is there). You aren't going to build a trillion-gallon tower, my friend, even if you're Trump and you build everything HUGE.
For the US we'd need roughly 1,000 of them the size of Lake Mead (250 square miles). I'll be quite impressed if you can come up with ONE suitable location, and we'd need a thousand.
There are dam few places left with a couple hundred feet of head. Given our actual geography, you'd flood basically the entire area between the Appalachians and almost to the Rockies by damming Louisiana. The flooded area would include Kansas, Missouri, Kentucky, Tennessee, Alabama, and part of Texas. Alternatively, if you built a thousand-mile dyke, you could use Utah, Eastern Colorado, Wyoming, Nevada, Arizona, and half of New Mexico. I may still have some graphics from the modeling if you'd care to see the exact area.
The summary is poorly written too, and misleadingb likely because certain sentences are copy-pasted from an article that uses a certain "trick".
The summary repeatedly makes claims about "all their energy needs", which is false and misleading. The goals have to do with percentages of ELECTRICITY, not energy. Most energy usage isn't electricity; it's gas, diesel, heating oil, etc. If a power plant could provide 100% of a town's electricity, that would be about 25% of their energy. To replace gas and diesel, you'll need four times as much, or what this summary would call "400%".
It is common when hyping solar to switch back and forth between using "energy" to actually mean "energy" and "accidentally" using the word "energy" to mean "electricity". That way you can divide two unrelated numbers to say "foo provides 90% of the energy used by bar". Or example "a cell phone battery has enough energy to run a car for 10 minutes at 60 MPH" (we're just talking about the *electricity* the car uses, not the the gas, wink wink).
> There are hydroelectric dams in use today that were built more than a century ago
Yes, 100 years ago they built hydroelectric dams the places where the geography was such that it makes sense to do so. As you said, we still get some benefit from that. Hoover dam generates 3.5 Twh/year (and flooded 250 square miles).
The good spots are already is use, by and large. There are actually *fewer* good spots now than 100 years ago. The Banqiao hydroelectric dam killed hundreds of thousands of people. It flooded thoudands of square miles and the "tidal wave" demolished everything in a 500 square mile area. The 1956 dam failure at Niagra Falls only killed a few people, a major failure at Niagra now would have perhaps 300,000 casualties. So logically we should be *removing* hydroelectric from places that have become heavily populated rather than adding more.
Another commenter gave you an idea of the scale you'd need for towers to work. In some weird circumstance where you need to power a remote outpost and you want to spend millions of dollars on a demonstration project, sure it *can* be done, to power one building or something. Just not at all feasible on a large scale.
Slashdot Mirror
That's interesting. I can't quite decide if it's useful or goofy. Maybe both. I've done something similar when it makes sense - very recently in fact.
Once I saw this program, with a whole company based on the program, which accepts absolutely anything as free-form text input, or even voice and pictures. If the input resembles a mathematical expression it returns the result of evaluating the expression. Even math with words like "5 grams in ounces". If you give it a picture as input, it returns similar pictures. If you give it input that resembles an address, it returns a map to that address. This strange program, called Google, has been moderately successful.
Extending your idea a bit, rather than copy-pasting those lines, one could have it as a function get_arg_objects(). Yes, it would be a very short function. The Linux kernel uses very short functions like that, and Linux is a tad successful. In fact, many C, perhaps most, programs use one-line functions like that - they call them macros.
Your code reminds me of a strange function in Perl called wantarray(). It allows your function to return different types, depending on that the caller seems to want. So you can easily handle of these appropriately:
My_number = foo(bar);
My_array_numbers = foo(bar);
foo(bar);
That's funny; as I wrote that it didn't occur to me we used to have physical devices called pagers, though they were actually pagees (they got paged). I was thinking of thr monitoring systems that page people.
As you said, the common way of getting software requirements doesn't work too well, and certainly doesn't work *reliably*.
I have a book from the 1970s that describes many of the programs I use every week. They still serve the requirements 40 years later. I'll come back to that set of programs, and how they predicted requirements 40 years down the road, at the end of my post.
Before getting to the 40 year old programs that are still used daily around the world, this topic reminds me of one of the best software design tips that I've been taught. In retrospect it seems obvious, but many programmers haven't thought to do it, and most don't insist on doing it.
90% of the time, you're writing software to better do something that's currently being done some other way. Perhaps you're replacing legacy software, perhaps it's currently being done "manually", people entering data one item at a time. Perhaps you're replacing a paper-based system. Most of the time, you're replacing *some* method of doing the same task.
It logically follows, then, that to fully understand the process, it's requirements and idiosyncrasies, you can watch the people actually doing it. Even better, have them show you how they do it, then try to do the job yourself while they watch and correct you or point out things to be careful of. Take notes during this. Most likely, the way they are using the old system is NOT how it was designed to be used, because the designers of the old system weren't clear on the requirements. But users find a way of meeting their requirements. Watching how they do that shows you what they actually need to get their job done.
Already just by watching them do the task you'll understand the requirements far better than you would by having a meeting with their boss's boss (the common, bad, way to get requirements). After watching them do the task, next ask them two questions:
What about the current process or tools is frustrating for you, or slows you down?
Pretending *anything* is possible, what would your impossible wishes be for this?
The second question often elicits ideas that allow the programmer to say "I can do that, that's easy". Then you begin to glow with heavenly lights because they thought their wish couldn't possibly be granted. Truly, I've done EASY programming tasks that have garnered me a reputation for being able to do the impossible, simply by asking the users what impossible features they wish I could provide. Their conception of what's easy and what's impossible is totally unrelated to what a good programmer can actually do. (You've probably noticed users often think it should be easy for us to do something that's actually nearly impossible. The flip side of that same ignorance is that they think we can't do stuff that we can actually do pretty easily.)
I didn't come up with any of this myself, these aren't my genius ideas and I wouldn't expect anyone else to think of these things. These are things I've been taught along the way, and I wouldn't expect another programmer to think of them, until they are also taught these ideas.
One more thought, or set of thoughts about foreseeing requirements. I was also taught that you can, fairly easily, plan for and program for future requirements without knowing what those future requirements will be. There are two major ways of doing that, both closely related. One is to avoid hardcoding unnecessary limitations. As an example, configuration for my software never has the user provide a configuration value. Instead, each configuration item is a LIST. If my software can send email notifications, it isn't configured with an email address to send to, it's configured with a list of email addreses. If it can read from a data file, it can read from a list of data files, etc. In the code, the added flexibility requires just this additional code:
foreach {
}
That's it. Just "foreach" whenever a configured value is used makes the whole system far more flexible. This is an example of not ar
> For programming skill, I'm going to suggest Zero Bugs and Program Faster
I second that, good book. Specifically it's a collection of good ideas, each of which takes about ten minutes to read. Zero Bugs and Program Faster would be an excellent choice if you want to spend just a few minutes each day, to have continuous slow improvement. It was my bathroom reading for a while and it was perfect for that.
(If you assembled the top 50 best forum posts related to creating robust software, you'd end up with something like this book - about 50 seperate good ideas that are only loosely related.)
Another way to use that book would be to read the same short section each day for a week, so by the end of the week the idea has found a permanent home in your brain.
> You see, I like to have my clocks all reading the same time, so almost all the clocks in my house are atomic clocks and keep themselves sync'ed with WWV.
Your radio synchronized clocks* are accurate to within a about 200ms or so. Using NTP, your clocks can all read the same time to within about 1ms. Any computer or computing device (such as even a consumer grade wireless router) includes a NTP client. You set one device as the master for your house. It syncs to a couple of nearby tier 2 servers, then all your other clocks sync to the local master, which is only nanoseconds away. That can be far more accurate than syncing to a source a thousand miles away, over a 60Khz radio signal.
* Unless you spent at least $1,500 on each clock, what's advertised as an "atomic clock" is actually a radio synchronized clock. Internally it keeps time with a quartz crystal, just like any clock you'd find at the dollar store. However once or twice per day it tries to sync to the radio signal which is loosely synchronized to an actual atomic clock. Operating at only 60Khz, the WWV is significantly less accurate than something like the signals CDMA and GSM phones use.
> Teach them to have pride in their work, and do things well or not do them
With just three hours, if it's not three hours every month, I think this is on the right track. In limited time, you may get the best bang for the buck teaching them how (and why!) to learn rather than teaching technical details.
You can present things like code review (peer review) and automated tools that look for code smells. The dangers of stackoverflow.com and how to know which answers are good.
First, however, you need the WHY. Why should they write better code? Why should they care? I'm known for pointing out how much time and energy we spend "putting out fires" and suggesting instead that we fireproof things up front. I'm all about avoiding having pagers go off on the weekend.
People do things because a) they want to and b) they can. If you just present a skill or tool, they *can* use it, but they won't unless they *want* to. What pain they currently experience can be relieved by following your suggestions?
I also like to save my work locally. I don't like to do everything via the cloud. Let's be specific about what that means:
The cloud:
The real work of the application is done on some company's servers. Your machine is only the UI.
Web Assembly and asm.js (and C, C#, Swift etc):
The application runs on your local computer. The whole thing is on your computer, not just the UI.
Javascript is rather slow (thousands of times slower than C), so you don't do video editing in Javascript, Javascript sends your data off to some server that does the actual work. C, C#, Swift, and Web Assembly are fast, so they can do video editing locally, without sending anything to any server.
In C, C#, Swift, or Web Assembly you *could* write an application to send the completed output to Dropbox or Google Drive, but there is no need to do that. You can save your work locally if you want to.
The only required difference between the traditional applications you're accustomed to and Web Assembly applications is that Web Assembly applications don't have to be installed. Both do the work locally, and can save the work locally - even on a device with no network connection. Obviously to get the application in the first place, any application, you need either a network correction, a USB stick, or some other way of getting the code to your computer.
> Can you give an example what you mean by belt and suspenders approach?
Essentially I mean wrapping one algorithm within another, such that cracking it requires cracking BOTH algorithms.
I don't know which algorithms we'll be using 10 years from now, but for sake of illustration let's pretend it's good old Diffie-Hellman. For the moment, we'll pretend we think DH is quantum resistant. With DH, each party sends their modulus in the clear. Because you can't solve the discrete logarithm problem, knowing the modulus doesn't let you compute the key. Suppose, however, that a clever person might figure out how to use quantum computers to solve the discrete logarithm and therefore crack DH (we're pretending we didn't expect that). What we can do is instead of sending the modulus in the clear, send it via some other algorithm Y() from an unrelated family. In that way, if the attacker cracks DH generally, that does them no good because the essential part of the DH exchange is invisible to them, protected by Y(). Cracking Y(), it does them no good - that only gets them the computed modulus that was originally intended to be sent in the clear anyway.
Another approach that does basically the same thing would be:
1) Use asymmetric algorithm A() to compute symmetric key ka, as normal.
2) Use asymmetric algorithm B() to compute symmetric key ba, as normal.
3) Use ka xor kb as the actual symmetric key.
Once again the attacker can succeed only by cracking both algorithms A() *and* B().
One should be cautious when combining algorithms; in some cases the combination is weaker than either algorithm alone. For example, md5(sha1(plain)) is weaker than either md5(plain) or sha1(plain). One shouldn't combine algorithms willy-nilly without understanding the consequences, but if done carefully you can guarantee that the combination is stronger than either algorithm alone. (For example, concatenating sha1(plain) with md5(plain) is stronger than either sha1 or md5 - but also results in a hash much longer than either algorithm does alone.)
Of course, it would also be a mistake to combine two *related* algorithms. XORing keys exchanged by two algorithms which both provably depend on discrete logarithm doesn't make it much stronger - if they can solve discrete log, they can crack both algorithms. One would need to combine two unrelated algorithms which depend on different hard peoblems as their primitives.
In case you're wondering, yes, I do security for a living. :)
> Can you give an example what you mean by belt and suspenders approach?
Essentially I mean wrapping one algorithm within another, such that cracking it requires cracking BOTH algorithms.
I don't know which algorithms we'll be using 10 years from now, but for sake of illustration let's pretend it's good old Diffie-Hellman. For the moment, we'll pretend we think DH is quantum resistant. With DH, each party sends their modulus in the clear. Because you can't solve the discrete logarithm problem, knowing the modulus doesn't let you compute the key. Suppose, however, that a clever person might figure out how to use quantum computers to solve the discrete logarithm and therefore crack DH (we're pretending we didn't expect that). What we can do is instead of sending the modulus in the clear, send it via some other algorithm Y() from an unrelated family. In that way, if the attacker cracks DH generally, that does them no good because the essential part of the DH exchange is invisible to them, protected by Y(). Cracking Y(), it does them no good - that only gets them the computed modulus that was originally intended to be sent in the clear anyway.
Another approach that does basically the same thing would be:
1) Use asymmetric algorithm A() to compute symmetric key ka, as normal.
2) Use asymmetric algorithm B() to compute symmetric key ba, as normal.
3) Use ka xor kb as the actual symmetric key.
Once again the attacker can succeed only by cracking both algorithms A() *and* B().
One should be cautious when combining algorithms; in some cases the combination is weaker than either algorithm alone. For example, md5(sha1(plain)) is weaker than either md5(plain) or sha1(plain). One shouldn't combine algorithms willy-nilly without understanding the consequences, but if done carefully you can guarantee that the combination is stronger than either algorithm alone. (For example, concatenating sha1(plain) with md5(plain) is stronger than either sha1 or md5 - but also results in a hash much longer than either algorithm does alone.)
Yeah that statement from the SEC is ridiculous. There's never been any hint of fraud around any Bitcoin exchange. Okay maybe a couple of small exchanges have had issues, but never the big exchanges that handle 3/4 of all Bitcoin transactions, like Mt Gox. There could never be any fraud at Mt Gox.
Yes, it's now slightly less stinky than something that resembles moldy coffee grounds left in the coffee maker over the holidays, or Balmer's ass hole.
It seems all programming languages suck. C, after decades of careful revision, is well suited to certain tasks, but not the tasks that most of us do most of the time.
Whatever is happening right now is Bush's fault. At least, that's what CNN has been telling me for the last 28 years.
> Presume it takes 20 days to transport the batteries and maybe another 30-40 to build them all (probably optimistic), they would be left with maybe a month to design, install and test the whole thing.
So you would build it and deliver it, THEN start designing it? A Scrum advocate I'm guessing.
I used to talk like that about PHP. PHP has greatly improved over the years.
> I wonder whether being behind load balanced proxy servers might have anything to do with it.
Anyone else having similar problems?
Yes, proxies correlate well to bots. Not all attempts from proxies are bots, but most attempts from bots come through proxies. Open proxies especially. Open proxies are bad anyway, so make sure your proxies aren't open. If possible, use a firewall to limit access to your proxies by IP address.
The last link in the summary (Cisco Talos) includes a Windows payload.
In 1999 the Apache Foundation got Tomcat, given to them by Sun. That may have been Apache's first project other than httpd.
What annoys me is that people I work with call all of the 50 or so different projects "Apache", without further specification. I'm well-versed in the Apache httpd code, I've contributed patches and I know configuration tricks and such. So when someone says "I'm having trouble with Apache" I go over to help, only to discover they're working on some Java thing.
LTE uses 5ms-10ms frames. So still, that's 100-200 switching decisions per second, per connection.
GSM data is sent in 156-bit (18 byte) frames, which are then combined into superframes. So anyway the prioritization decision is made every few bytes - millions of times for one video. It needs to be fast, very fast, and a flag indicating "high" or "low" priority is fast - much much faster than computing and comparing a numerical score for each frame to see who is highest, then multiplying the reciprocal of that by time in queue.
Also, long before T-Mobile started prioritizing based on usage so far in month, network protocols and network equipment was built built with traffic classes, not traffic scores. T-Mobile is using pre-existing functionality. It's arguable which provides a "better" customer experience, so they might as well use the simple, efficient, pre-existing method.
We may be talking about two different things. Obviously you can pump water into a paper cup, or a swimming pool or whatever. Let's define exactly what we're discussing.
> We are not talking about CAPACITY.
> We are talking about weather or not you need a Hoover Dam like plant design.
Well I said if you want to power a building, you can use any of many designs. If you want to power cities, I said, you're looking at basically a hydroelectric dam type of design. So yes what I said is all about capacity - the capacity to power a city or country, as opposed to a building. Let's get a bit more specific ...
The suggestion was:
>>>> Take the excess energy generated and pump the water up, then release it through a turbine when your solar farm lacks sun
Okay so we're talking about what you need to do when the solar-electric plant isn't getting much sun. Note it doesn't say anything about load, it says "when your solar farm lacks sun". We'd like for solar-electric to supply a significant portion of our energy needs. Perhaps 25% would be good, that would be equal to 100% of our current *electricity* consumption.
Looking at the current weather forecast, Germany will be covered in clouds Monday, Tuesday, and Wednesday, meaning they'll have minimal solar power power generation for three days. A couple times each year, most or all of Europe is covered by a large storm system for four or five days. So if you're going to be dependent on solar for a significant portion of your daily energy, you're going to need to store enough to power Europe for a two to three days (which will stretch to four or five days because you still get *some* generation despite the cloudy weather).
So that's what *I'm* talking about, what you need in order to make it safe to rely on solar electric as a primary source of energy. You need the capacity to provide millions of people will their energy needs for several cloudy days in a row. You don't get there with 70,000 gallon towers, or 200,000 gallon ponds. To make solar-electric reliably power major cities, you need reservoirs that are hundreds or thousands of square kilometers each, and not just one or two of them, but many, many of them.
>> Might I suggest you read the stories rather than just look at the pictures
> Nope, the point of the stories are precisely the pictures
Well, if you don't care to read even the sources you cite, I don't suppose I can help you. Intentional ignorance is permanent ignorance. They do, however, say that you're wrong by orders of magnitude.
>> Enough to charge 20 Teslas
> how you come to the idiotic idea that one of the reservoirs would only charge 5 Teslas is beyond me.
You're not lying, you *really* hate to read, don't you.
Storage capacity required to charge just ONE car, as an example load: 90Kwh
So the total storage capacity of the entire country could, as example, charge half a million cars and do nothing else - no lights, no cooking, no hot water - in a country with 80 million people. As long as you're happy to share your car 160 other people, and use no other energy for anything else, you've got enough storage.
Might I suggest you read the stories rather than just look at the pictures. One of the stories you linked to points out that a "fact" you stated is wrong by orders of magnitude.
In the stories you linked to, you'll also find the capacities of those reservoirs which consist of a dam all the way around - enough to charge 20 Teslas. Germany has 80 million people. Do you think they're going to build a million or so such reservoirs?
> A hydro pumped storage plant is not the same thing as a hydro dam. Facepalm.
Actually that's *exactly* what it is, unless you're planning on powering one building, in low-power mode, for a few hours. (That you can do with a tower - power the emergency lights in a work building overnight when nobody is there). You aren't going to build a trillion-gallon tower, my friend, even if you're Trump and you build everything HUGE.
For the US we'd need roughly 1,000 of them the size of Lake Mead (250 square miles). I'll be quite impressed if you can come up with ONE suitable location, and we'd need a thousand.
There are dam few places left with a couple hundred feet of head. Given our actual geography, you'd flood basically the entire area between the Appalachians and almost to the Rockies by damming Louisiana. The flooded area would include Kansas, Missouri, Kentucky, Tennessee, Alabama, and part of Texas. Alternatively, if you built a thousand-mile dyke, you could use Utah, Eastern Colorado, Wyoming, Nevada, Arizona, and half of New Mexico. I may still have some graphics from the modeling if you'd care to see the exact area.
The summary is poorly written too, and misleadingb likely because certain sentences are copy-pasted from an article that uses a certain "trick".
The summary repeatedly makes claims about "all their energy needs", which is false and misleading. The goals have to do with percentages of ELECTRICITY, not energy. Most energy usage isn't electricity; it's gas, diesel, heating oil, etc. If a power plant could provide 100% of a town's electricity, that would be about 25% of their energy. To replace gas and diesel, you'll need four times as much, or what this summary would call "400%".
It is common when hyping solar to switch back and forth between using "energy" to actually mean "energy" and "accidentally" using the word "energy" to mean "electricity". That way you can divide two unrelated numbers to say "foo provides 90% of the energy used by bar". Or example "a cell phone battery has enough energy to run a car for 10 minutes at 60 MPH" (we're just talking about the *electricity* the car uses, not the the gas, wink wink).
> There are hydroelectric dams in use today that were built more than a century ago
Yes, 100 years ago they built hydroelectric dams the places where the geography was such that it makes sense to do so. As you said, we still get some benefit from that. Hoover dam generates 3.5 Twh/year (and flooded 250 square miles).
The good spots are already is use, by and large. There are actually *fewer* good spots now than 100 years ago. The Banqiao hydroelectric dam killed hundreds of thousands of people. It flooded thoudands of square miles and the "tidal wave" demolished everything in a 500 square mile area. The 1956 dam failure at Niagra Falls only killed a few people, a major failure at Niagra now would have perhaps 300,000 casualties. So logically we should be *removing* hydroelectric from places that have become heavily populated rather than adding more.
Another commenter gave you an idea of the scale you'd need for towers to work. In some weird circumstance where you need to power a remote outpost and you want to spend millions of dollars on a demonstration project, sure it *can* be done, to power one building or something. Just not at all feasible on a large scale.