The first thing that LibreOffice did was import all of Novell's patches that OpenOffice rejected because of their dubious legal status (they were written with documentation provided by Microsoft under their patent agreement with Novell). So it has better support for a lot of MS Office things than OO.o.
Not so much the congress-denizens themselves, but the people who contribute to their campaigns and employ their constituents. If you're a senator, and you propose closing a tax loophole, you're likely to get a visit from a lobbyist saying 'my client has a factory in your state that employs 200 people. Without that loophole, we'd have to relocate the jobs to {this week's offshoring nation of choice}'. Senator votes for it, and the next election his opponent runs a campaign about how he cost the state 200 jobs in a single vote. More likely, the senator backs down and tries to find a loophole that none of the companies in his state are using. Unfortunately, when he does, he finds senators from other states experiencing the same pressure and the proposal never makes it out of committee.
SIP is a nightmare when it comes to the ubiquitous NAT'd firewalls everyone has.
Seems fine to me. I entered the STUN server address when I set up the account, and my SIP phone has no problems making calls.
Whoever designed the SIP codec didn't learn from FTP./quote.
The SIP codec? Ah, you don't know what you're talking about. You could have put that at they start of your post and saved us some time...
Why RTFA? The summary makes it quite clear. It's actually a very good test application. Bicycle breaks are mechanically simple and cheap to construct, but require the same sort or control latency as a lot of aerospace applications. It's a lot cheaper to stick an experimental control system on a bike than an aircraft, and if it doesn't work it's probably a lot less painful...
Sorry, you're right. However, reading TFA, it seems that the summary is a little too abridged. Cutting down mature forests and then planting new trees does reduce the total carbon dioxide, and that's what they're actually talking about.
Secondly as for the idea that we will someday no longer need programming languages and to simply state what we want and it magically write compile debug and give you exactly what you want not likely
If you read the Stantec ZEBRA's programming manual (from 1958), it tells you that there are two instruction sets and recommends that you use the smaller one dubbed 'simple code'. This comes with some limitations, such as not being able to have more than 150 instructions per program. This, it will tell you, is not a serious limitation because no one could possibly write a working program more than 150 instructions long.
Compared to that, a language like C is close to magic, let alone a modern high-level language.
I think that's part of the problem. The other part is that most humans actually suck at giving orders. Try this for an experiment: get a set of lego bricks and - using nothing but voice command - try to get someone else to assemble a structure that you want. You'll find it really hard and incredibly frustrating, and that's with an intelligent human interpreting and following the instructions. Now try building the structure yourself. Much easier (assuming you have the use of your hands).
There's a reason that most HCI research into voice control has focussed on disabled people for the last decade or so: if you have working hands, they're often a much better way of issuing instructions. The claim in TFA is bullshit:
The advantage of using speech over other interaction paradigms is that we have honed its use over thousands of years. It is entirely natural for us to talk to one another. Talking is one of the first things we learn how to do as children
The advantage of using touch over other interaction paradigms is that we have honed its use over thousands of years. It's entirely natural yo interact with devices by touching them. Touching things is one of the first things we learn to do as children. Children generally don't learn to talk for a couple of years after they're born. They learn to touch within seconds, and they learn to manipulate their surroundings with their hands almost immediately. This is (one of the reasons) why the direct manipulation paradigm is so powerful.
Until OSX can copy more than 800 MB from a network share without the OS locking up to the point that I have to hard boot the machine, I think your claims may be a bit premature...
I just set up a NAS, and I have two Macs here that have copied over 100GB to it and over 10GB from it in the past couple of days...
You're confusing sales with profits. This has been Nokia's problem. They still have more market share than all of their competitors combined, but it's focussed on the low end where the margins are tiny. I don't think Apple's ever had more than 5% of total phone sales - last time I looked they were at 2%, but I think they grew since then - but it was the most profitable 2%. You can make $100 profit on each sale on something like an iPhone and people will still buy it. When phone retails for $50, you need to ship a hundred times as many to make the same sort of profits.
If your company is growing at a rate slower than the rest of the market, then this is usually a bad sign, so this is what Wall St commentators pick up on. They miss the fact that many of these tech markets go from being niches owned by one or two companies to being large commodity markets over a short period. During this time, it's more accurate to say that the old market is part of a growing new market, rather than that the old market has grown. It should be a wakeup call for the companies in question though. SGI was in the state that RIM is in just around the time nVidia was formed: they were doing well in a market that was just about to shrink a lot.
If the expression that denotes the called function has a type that does not include a prototype, the integer promotions are performed on each argument, and arguments that have type float are promoted to double.
Followed by:
If the number of arguments does not equal the number of parameters, the behavior is undefined.
And:
If the function is defined with a type that does not include a prototype, and the types of the arguments after promotion are not compatible with those of the parameters after promotion, the behavior is undefined, except for the following cases:
So, in this case it's probably fine, because this call won't result in any integer or floating point promotions, but in the general case the language quite definitely does not expect calling a function without a prototype to work. There is no way, for example, to call a function that takes a char or a float as a parameter and have it work without a prototype or cast, except by lucky coincidence of the calling conventions. For example, on most platforms if the char is the first parameter then it will be passed in a register, and the promoted version will use the same register, but later arguments may be spilled onto the stack.
Maybe, at least be helping to publicise an unpopular proposal. The more amusing bit was 'VeriSign: 0'. Given the amount of crap they've pulled and got away with over the last few years, It's more like 'Slashdot: 1, VeriSign: 23'.
Fortunately, when you clicked the 'I agree' button, you gave Facebook a commercial, transferable, sublicensable, license to anything that you uploaded, and you agreed that you owned the copyright, or the right to make such a grant, on everything that you uploaded.
AT&T would send you tapes of the UNIX source code for a couple of hundred dollars. That was very cheap, in comparison to other operating systems. That's why UNIX was used for teaching operating systems to an entire generation of students. AT&T's change of the licensing conditions and the increasing complexity of the UNIX code after version 7, were the two main reasons Tanenbaum wrote MINIX.
Yes, to both. My email is hosted on a server that I do control, but as soon as it is sent to someone else's server, it's effectively public. Internet banking data is shared with credit rating agencies, as noted in the T&Cs attacked to my bank account.
Smalltalk ran all of the code on the Xerox Alto, including the entire windowing system, in 512KB of RAM. It used a lot of memory in comparison with 64KB CP/M programs, but in absolute terms it really wasn't that much. IBM is the only 'big player' I can think of behind Smalltalk, and they only halfheartedly pushed it.
(Not the original poster) The language I use is mainly C, but that doesn't mean that it lacks flaws. The first low-level language that I learned was PL/M, which had a few nice things that C lacks. For example, pointers in PL/M were a slightly higher-level construct, so you could easily represent segmented architectures. On x86, you could use the hardware segmentation support to bounds check your arrays and other data structures automatically - buffer overflows were basically impossible unless you actively tried to write them. If PL/M had been more popular than C, then AMD would have extended the segmentation support with x86-64, instead of killing it completely. We have a couple of decades of buffer overflows to thank C for.
It's not needed in K&R C. Printf is a variadic function, so unless your architecture is really weird and has a different location for the first pointer parameter to a function depending on whether it's variadic or specified (none that I'm aware of do), then it will work as expected.
But when it was created, it was another world, and low level languages were needed because there was a lot less computing power available, and you didn't want to waste any.
To put this in perspective:
The Xerox Alto ran Smalltalk. It ran a VM, which was written in a static subset of Smalltalk that was natively compiled, and the rest of the code was interpreted bytecode from a dynamic, object-oriented language, including a GUI, an introspective development environment, and some apps. It required a microcoded BitBlt instruction to be able to achieve a usable speed. This was on a processor that didn't even reach 1MHz, with half a meg of RAM.
Objective-C was created in 1986 because the processor and memory requirements of Smalltalk were deemed unreasonably high.
The FSF came into being because RMS had a printer with a buggy driver and couldn't fix it. With Smalltalk, the image contains all of the code. In a traditional Smalltalk environment, it's basically impossible to distribute code that the end user can't fix. If RMS' printer driver had been in Smalltalk, he'd have just fixed it and moved on, not founded the FSF.
Slashdot Mirror
The first thing that LibreOffice did was import all of Novell's patches that OpenOffice rejected because of their dubious legal status (they were written with documentation provided by Microsoft under their patent agreement with Novell). So it has better support for a lot of MS Office things than OO.o.
Not so much the congress-denizens themselves, but the people who contribute to their campaigns and employ their constituents. If you're a senator, and you propose closing a tax loophole, you're likely to get a visit from a lobbyist saying 'my client has a factory in your state that employs 200 people. Without that loophole, we'd have to relocate the jobs to {this week's offshoring nation of choice}'. Senator votes for it, and the next election his opponent runs a campaign about how he cost the state 200 jobs in a single vote. More likely, the senator backs down and tries to find a loophole that none of the companies in his state are using. Unfortunately, when he does, he finds senators from other states experiencing the same pressure and the proposal never makes it out of committee.
You might want to check how much Goldman Sachs 'invested' in Facebook before making that comment...
I wonder how often their mails get caught by spam filters...
SIP is a nightmare when it comes to the ubiquitous NAT'd firewalls everyone has.
Seems fine to me. I entered the STUN server address when I set up the account, and my SIP phone has no problems making calls.
Whoever designed the SIP codec didn't learn from FTP. /quote.
The SIP codec? Ah, you don't know what you're talking about. You could have put that at they start of your post and saved us some time...
Why RTFA? The summary makes it quite clear. It's actually a very good test application. Bicycle breaks are mechanically simple and cheap to construct, but require the same sort or control latency as a lot of aerospace applications. It's a lot cheaper to stick an experimental control system on a bike than an aircraft, and if it doesn't work it's probably a lot less painful...
Sorry, you're right. However, reading TFA, it seems that the summary is a little too abridged. Cutting down mature forests and then planting new trees does reduce the total carbon dioxide, and that's what they're actually talking about.
Removing a mature forest would have minimal impact on carbon dioxide levels.
Unless you burn the wood. For fuel. As they did (except for small amounts used for building)...
Secondly as for the idea that we will someday no longer need programming languages and to simply state what we want and it magically write compile debug and give you exactly what you want not likely
If you read the Stantec ZEBRA's programming manual (from 1958), it tells you that there are two instruction sets and recommends that you use the smaller one dubbed 'simple code'. This comes with some limitations, such as not being able to have more than 150 instructions per program. This, it will tell you, is not a serious limitation because no one could possibly write a working program more than 150 instructions long.
Compared to that, a language like C is close to magic, let alone a modern high-level language.
There's a reason that most HCI research into voice control has focussed on disabled people for the last decade or so: if you have working hands, they're often a much better way of issuing instructions. The claim in TFA is bullshit:
The advantage of using speech over other interaction paradigms is that we have honed its use over thousands of years. It is entirely natural for us to talk to one another. Talking is one of the first things we learn how to do as children
The advantage of using touch over other interaction paradigms is that we have honed its use over thousands of years. It's entirely natural yo interact with devices by touching them. Touching things is one of the first things we learn to do as children. Children generally don't learn to talk for a couple of years after they're born. They learn to touch within seconds, and they learn to manipulate their surroundings with their hands almost immediately. This is (one of the reasons) why the direct manipulation paradigm is so powerful.
Until OSX can copy more than 800 MB from a network share without the OS locking up to the point that I have to hard boot the machine, I think your claims may be a bit premature...
I just set up a NAS, and I have two Macs here that have copied over 100GB to it and over 10GB from it in the past couple of days...
You're confusing sales with profits. This has been Nokia's problem. They still have more market share than all of their competitors combined, but it's focussed on the low end where the margins are tiny. I don't think Apple's ever had more than 5% of total phone sales - last time I looked they were at 2%, but I think they grew since then - but it was the most profitable 2%. You can make $100 profit on each sale on something like an iPhone and people will still buy it. When phone retails for $50, you need to ship a hundred times as many to make the same sort of profits.
If your company is growing at a rate slower than the rest of the market, then this is usually a bad sign, so this is what Wall St commentators pick up on. They miss the fact that many of these tech markets go from being niches owned by one or two companies to being large commodity markets over a short period. During this time, it's more accurate to say that the old market is part of a growing new market, rather than that the old market has grown. It should be a wakeup call for the companies in question though. SGI was in the state that RIM is in just around the time nVidia was formed: they were doing well in a market that was just about to shrink a lot.
If the expression that denotes the called function has a type that does not include a prototype, the integer promotions are performed on each argument, and arguments that have type float are promoted to double.
Followed by:
If the number of arguments does not equal the number of parameters, the behavior is undefined.
And:
If the function is defined with a type that does not include a prototype, and the types of the arguments after promotion are not compatible with those of the parameters after promotion, the behavior is undefined, except for the following cases:
So, in this case it's probably fine, because this call won't result in any integer or floating point promotions, but in the general case the language quite definitely does not expect calling a function without a prototype to work. There is no way, for example, to call a function that takes a char or a float as a parameter and have it work without a prototype or cast, except by lucky coincidence of the calling conventions. For example, on most platforms if the char is the first parameter then it will be passed in a register, and the promoted version will use the same register, but later arguments may be spilled onto the stack.
Maybe, at least be helping to publicise an unpopular proposal. The more amusing bit was 'VeriSign: 0'. Given the amount of crap they've pulled and got away with over the last few years, It's more like 'Slashdot: 1, VeriSign: 23'.
Fortunately, when you clicked the 'I agree' button, you gave Facebook a commercial, transferable, sublicensable, license to anything that you uploaded, and you agreed that you owned the copyright, or the right to make such a grant, on everything that you uploaded.
AT&T would send you tapes of the UNIX source code for a couple of hundred dollars. That was very cheap, in comparison to other operating systems. That's why UNIX was used for teaching operating systems to an entire generation of students. AT&T's change of the licensing conditions and the increasing complexity of the UNIX code after version 7, were the two main reasons Tanenbaum wrote MINIX.
Most of Windows is the libraries. It's not like Linux, where the name just describes the kernel...
Yes, to both. My email is hosted on a server that I do control, but as soon as it is sent to someone else's server, it's effectively public. Internet banking data is shared with credit rating agencies, as noted in the T&Cs attacked to my bank account.
Smalltalk ran all of the code on the Xerox Alto, including the entire windowing system, in 512KB of RAM. It used a lot of memory in comparison with 64KB CP/M programs, but in absolute terms it really wasn't that much. IBM is the only 'big player' I can think of behind Smalltalk, and they only halfheartedly pushed it.
(Not the original poster) The language I use is mainly C, but that doesn't mean that it lacks flaws. The first low-level language that I learned was PL/M, which had a few nice things that C lacks. For example, pointers in PL/M were a slightly higher-level construct, so you could easily represent segmented architectures. On x86, you could use the hardware segmentation support to bounds check your arrays and other data structures automatically - buffer overflows were basically impossible unless you actively tried to write them. If PL/M had been more popular than C, then AMD would have extended the segmentation support with x86-64, instead of killing it completely. We have a couple of decades of buffer overflows to thank C for.
It's not needed in K&R C. Printf is a variadic function, so unless your architecture is really weird and has a different location for the first pointer parameter to a function depending on whether it's variadic or specified (none that I'm aware of do), then it will work as expected.
But when it was created, it was another world, and low level languages were needed because there was a lot less computing power available, and you didn't want to waste any.
To put this in perspective:
The Xerox Alto ran Smalltalk. It ran a VM, which was written in a static subset of Smalltalk that was natively compiled, and the rest of the code was interpreted bytecode from a dynamic, object-oriented language, including a GUI, an introspective development environment, and some apps. It required a microcoded BitBlt instruction to be able to achieve a usable speed. This was on a processor that didn't even reach 1MHz, with half a meg of RAM.
Objective-C was created in 1986 because the processor and memory requirements of Smalltalk were deemed unreasonably high.
That today we would still be using pre-C languages, constructs and ideas?
Constructs like classes, ideas like garbage collection, closures, and higher-order functions?
The FSF came into being because RMS had a printer with a buggy driver and couldn't fix it. With Smalltalk, the image contains all of the code. In a traditional Smalltalk environment, it's basically impossible to distribute code that the end user can't fix. If RMS' printer driver had been in Smalltalk, he'd have just fixed it and moved on, not founded the FSF.