He is not suing anyone. Not everything involves someone getting sued. No-one is getting sued here.
Why else would you need amnesty? Why else would he be extending "amnesty" only until a certain date? Which, by the way, is not amnesty. It's a grace period. Hope this helps.
call it what you will, just a gesture to remove any doubt people might have over possible infringement. copyright rules can also vary internationally. I just set an arbitrary date. I will most likely extend it on a rolling basis after that date. there are no plans to sue anyone!
just for the record folks... I just posted this in response...
"urban myth. the only court case was the one with Ozemail, cited in the original thread. It cost both sides heaps to run the case and was settled out of court after the judgement was given. Trumpet Software did receive some $$$, but not on the scale you mentioned."
As for starting up, Trumpet Software grew out a lounge room from shareware regs alone, not with a huge cash injection from a court settlement or any VC $$$.
As for some of the other stuff, there's a fair bit of personal stuff which would be inappropriate for me to discuss, except it almost broke me to have to resign my position in the business in 2004 because of the divorce proceedings. There are also some other inaccuracies in the statements you made, but as you can understand it is just not appropriate for me to discuss the ugliness of the divorce proceedings and settlement in public (except to say it took almost 7 years through the courts, the longest case in Hobart I have been told).
What would be great is if Intel exposed their RISC instructions so that you could run it like a true RISC. Maybe there are already secret backdoors which would allow you to do this - some instruction to make it jump into RISC mode. Anyone got any ideas on this?
Should be retitled "HAZARDS OF BEING A PUBLIC FIGURE"
Since you leave me no choice but to answer the allegations in a public forum, here goes. Unfortunately this will will make me seen as a Linux or Unix basher which I am not.
I do recall being harassed by a couple of Linux zealots at a public meeting as usually happens.
I remember a conversation with someone which is roughly consistent with what you say except for a couple of points. I don't publicly use phrases like "xyz is shit" and "that's bullshit". I might speak in such terms among close friends but not to members of the public. If you don't have a tape recorder to back up your allegations, stop lying - it does your case no good.
I know this whole thing is fabricated because you say we use redhat linux in our organization. We have not ever and never will uses Linux for anything. I think it may have been installed once by an employee on their own personal hardware for a specific purpose (gaming server?) but that is the extent of how far Linux has ever made it into our place. It was removed when the employee fled the state seeking a "better" life.
The conversation if I remember rightly went similar to this but I can't remember anything word for word, it's too long ago. I will just dot point. The order of topics discussed may all wrong, but I will cover the issues you have raised.
- someone probes me about our OS which we've just announced in July 99. I only respond with what I am publicly prepared to disclose. I talk about the OS and what it is capable of at that time. explain that I can bring up a full internet server, 32 bit OS running from a single floppy, native and it comes up in a flash. This seems to fly over their head or the achievement otherwise ignored. They also seem to be amused at our apparent lack of progress.
- they are trying to make me look like an arsehole by trying to catch me off guard so I begin to be defensive. seems like they have an axe to grind.
- its clear they have a closed mind about all OSes apart from free ones, in particular Linux.
- they ask me about wine. I give an honest opinion - at that time I most likely say one of two things.. it depends on when the meeting took place which the person isn't willing to disclose.
Either I am aware of wine at this stage and say that
a) yes, I know of wine I say that wine is certainly more advanced than we are, but that I feel a direct approach at OS integration is better. I also express that wine has been taking a long time to achieve its target. They misinterpret my criticism. I probably raise anumber of ciritcisms but I honestly can't remember much more.
or
b) I am not aware of wine - tell me more - news to me, etc.
I'm fairly sure I was very aware of wine and its state of play at around Jul 99 so I think answered a) I can say there was a point at which I was alerted to wine by someone to which I may have been surprised or couldn't respond because of lack of
- they ask me about unix. I say I have nothing against unix, but that the IT world is bigger than Linux and Unix. They think I'm talking rubbish and can't believe anyone would not think that Unix & Linux are the best OS's in the world. I talk about why we shouldn't lock oursleves down with 70's technology and try to express some technical thought about why unix has inefficiencies and design flaws that make it not the best choice for the general public. I talk about how Joe everage doesn't give a hoot about unix and would have grave difficulties trying to install unix. I try to raise many of the other general criticisms about trying to force unix on the general public won't work. Again I seem to be talking to the walls.
- at some point the discussion over why I don't use Linux is raised. I probably point out that we use FreeBSD in house and for good reason. I prefer an OS with a pedigree. It's difficult for me to put into words what I have observed of Linux over the years and its process of development which makes me unwilling to trust it as a mission critical OS. I most likely express it by saying that I don't believe Linux is stable enough for our requirements. Very likely I again failed to get my point across.
- the issue of why I am even bothering with Windows emulation is raised through the discussion. I talk about what most of the industry is using and that asking people to switch to Linux or Unix to do their work is impractical.
I am sadly and deeply hurt by this public attack on my credibility, especially in my own home town.
If people like you got their way, I would turn my back on the whole industry. I am capable of doing other things and life is too short to squeeze them all in.
In a true Australian and especially Tasmanian tradition any success we have had has been flushed down the toilet because of the petty jealousy that runs rife in our town and the whole country. Classic tall poppy syndrome.
Face it, Tasmania is an IT backwater and will remain so until those in the industry learn to build each other up rather than tear down every achievement ever made. I have said this many times in Hobart and have been hated for it. This attack just adds weight to my argument.
As for your other comments about the way we run our business - we have a reputation for not being a pushover - you either shape up or ship out. It's a small town and gossip abounds when staff are encouraged to leave for whatever reason. That is a harsh reality in the modern business world. If you only knew the truth of what the business and employment community has done to us in Hobart you would swallow your words. Unfortunately I cannot discuss such things in public as some are pending criminal action.
For others reading this, you may think I am a fool for even responding to this troll. I have responded for your benefit so that you can see the level of hardship and personal attack that anyone of prominence goes through when trying to achieve their dream.
Perhaps you are frustrated that I *haven't* attended a Computer Society meeting for over 4 years as...
1) I'm not a member of the ACS.
2) Despite repeated requests for me to speak at a ACS meeting in Hobart, I've been too busy working on the OS to spare the time plus I have a busy company to run.
I'm sure those in the ACS branch in Hobart would be appalled to hear one of their members refer to me in such a manner. Like me to follow it up?
I have been involved in the multihoming debate for a couple of years now. I haven't gotten into the multi6 group yet for reasons of time, but I have already submitted a novell idea at an interim IETF meeting on the issue, which was well received. The ideas need to be progressed towards an I-D, but again time contraints slow me down. My idea centred around a mechanism for hosts to dynamically change the IPv6 address for active TCP connections with only minor enhancements to the IPv6 and TCP layers. The same idea can be extended to other protocols and is also backward compatible with existing Ipv6 infrastructure.
The whole point is that its impossible to route a very large network by meshing large numbers of nodes or networks in one location. Eventually the thing won't scale if you allow indiscriminate DFZ explosion. Even labeling (MPLS) will die when the network gets too big.
Hierarchical table management is the way to deal with it. The Ipv6 solution to the multihoming problem is to assign multiple network addresses. Packet delivery for at least one of those networks can be guaranteed under that scenario so the network infrastructure is certainly doing its job. It's up to the higher layer protocol designers to figure out how they should deal with hosts having multiple addresses and then the problem is licked.
If you consider that multihoming information is much longer lived than perhaps mobile IP, the solutions for dealing with the multiple addresses start to fall in place.
Perhaps its time I got back into the multi 6 debate again and get the issue resolved - I have to admit its the bugbear of Ipv6 deployment at the moment.
Having written a NAT, I know a little bit about what I'm talking about.
Study up on IPsec/IKE, and you'll find that having live unique Ip addresses at each end is essential to the security model. NAT breaks this.
As for the server stuff - yes it probably can be done, but how do you handle several web servers, all through a single IP address and the same public port 80. You have to choose another public port which then will start to break other things (e.g. routing filters), or decode the TCP data to attempt to work out where the stream is destined. You can probably do it by inspecting the data streams and directing traffic as appropriate, but this won't scale to large networks... too much CPU required.
As for FTP or any other protocol that passes IP addresses in the TCP stream, the NAT box has to decode the data and modify it in a protocol dependent manner. Ok for a small NAT newwork, but prohibitive in a large network. But for similar reasons above won't scale.
It would be a trivial matter for a CD ripper to validate the resulting rip to make sure it didn't do stupid things like signals that blow up speakers and such. It would just make the rip slower that's all.
Sounds like a whole bunch of FUD to me.
Not that I'm in favour of ripping CD's mind you. The poor musician is one who really gets screwed (after already being screwed by the recording companies).
wrong. There are large chunks of the world that can't get address space to do what they want. Especially Asia which is only now starting to get into the Internet. it is also estimated that giving every mobile phone over the next 10 years or so an IP address will also make us run out of addresses.
2. NAT is the answer? No, for true secure internet you need end to end connectivity. This means live IP addresses, not hiding behind NAT. Also NAT can't pass everything through. e.g. try to pass ESP for several devices through NAT. Also try to run several independent servers of the same service type (e.g. web sites) behind a NAT. Gets very difficult.
3. Routing for Ipv6 will fall apart because of the large routing tables?
Wrong. The way strong aggregation is defined in Ipv6 results in the Default Free Zone (DFZ) of the core internet being very small (designed to be < 8000 or so entries). That same aggregation policy applies to for TLA (top level aggregate), NLA (next level aggregate) and SLA (Site level aggregate). If people adhere to the rules, there will be no routers blowing up any time soon. Router lookups will be faster than they have ever been because of the strict aggregation boundaries.
As an aside, Ipv6 does not have a header checksum so routers will no longer need to checksum all headers as they pass through. This will also reduce router processing overhead.
To qualify (3) I must add that multihoming is done differently in Ipv6. No site will ever "own" their address space so it can never be advertised into the DFZ. This is the mistake that we learnt from IPv4. To multihome you will be required to have an address space from each provider (SLA/NLA or TLA) that you are multihoming to. This means that nodes in a multihomed site will potentially have more than one visible address on the internet to maintain connectivity. The details of how to deal with the multiple address issue are in the process of being sorted out, but I can assure you there are several solutions to the issue of multihoming in Ipv6.
4. Privacy is gone in Ipv6. (in case anyone wants to raise the point).
This has been debated before about the issue of your NIC address being publicized. It is a simple matter to anonymize the address and an I-D has already been done to deal with this.
So Ipv6 is not DOA as some would suggest. It's only a matter of time before people realize that it's absolutely required for the Internet to move forward.
Do your research and you'll find that Ipv6 is needed and will make life on the internet much more saner. The availability of reasonable address space is the fundamental one, and I'm sure the IAB/IETF can bring enough pressure to bear on providers to make sure everyone gets a fair share of this address space. Don't also forget that it's a free market - giving adequate address space can be a selling point for a competitive ISP.
Found it hard to find an appropriate title for this post, but hopefully others can get my drift.
I find it amazing that given the considerable understanding of economic monetary systems and the value of production etc. in these forums, that there is a lack of perception of the impact that open source software (in particular free software) is having on the software industry, and even the online industry as a whole.
There are two issues...
1) collective ownership of the software. Nobody has to pay for it, assigning an intrinsic exchange value of $0 for the software. There are hidden costs in "mining" the software (ISP costs, cost of storage and other infrastructure), but these are neglible in comparison to the true worth of a utility.
2) virtually unlimited replication. You create as many instances as your "warehouse" can contain. Sort of like printing your own money when you need more. This is the stuff of inflationary monetary policy.
Both of these factors effectively reduce the value of the software to the point where it becomes uneconomic to invest resources into creating better software, eventually stifling innovation. It's really an experiment in communism. At the moment, the open source movement is basking in the euphoria that usually accompanies such a revolution, but such euphoria won't last forever.
However, I believe that history will show itself in the future with the result that open source will suffer the demise of that of any economy based on collective ownership - it may be 5 years, or it could be 50. I guess it will take around 2-3 "generations" as I suspect it has a lot to to with social engineering - the zealots start the movement, the masses reap the short term benefits, the later generations reap the damage caused.
In the meantime, we might go through a period of "dark age" mentality because true innovation of software remains unrewarded due to the devaluation of software's true worth.
The sad thing is that I believe that large companys like Microsoft fully understand the economic principles behind open source, and are secretly embracing it and encouraging it to grow. It can only increase their hold on the software industry by the removal of smaller innovators like ourselves, and in the long run, they will be the Barons of the future.
I guess the firewalls/routers have their own reasons for rejecting such packets. The reality is that ECN in the spirit of not breaking backward compatibility should be able to work around these scenarios. It current;y doesn't which is why I suggest it needs to be sent back to the drawing board.
My suggestion is to try ECN first, if a RST is encountered, try again without ECN and mark the path as ECN unfriendly. If the firewall is dropping packets, then perhaps alternate TCP SYN's between ECN & non-ECN packets until a connection is established or timeout.
It is not a solution to insist that the errant routers/firewalls be replaced. The may have very good reasons for their paranoid rules and in many cases it may be impractical to perform an upgrade.
Consider also the case where the reserved TCP bits might be in use locally in a site for traffic management (perhaps in error). site policies might mandate that exploits using these bits be terminated ASAP.
Anyway, my main gripe is that the solution to the scenarios is not to fix the routers/firewalls, but to implement better workarounds in the protocol itself. The appropriate and well tested method of extending protocols like TCP is through header options, and not by manipulating the reserved bits.
I think the real problem is that ECN makes some wild assumptions about which bits in the headers to use. The Ipv4 TOS byte is overloaded to blazes. Bad idea to use that as it should have been considered no man's land, and there appears to be no escape mechanism to negotiate behaviour between two hosts.
Had I done this, I would have added the extra bits elsewhere... perhaps TCP header extensions.
Hint to implementors. I would attempt to see if a clear path exists for those bits to work before applying it to a circuit.
As I said before I think that the protocol is broken because the discovery mechanism is unreliable as we have now seen.
As someone who lives close to this hole (Tasmania, Australia), I have noticed the change for myself. I hope they are right because I am sick of getting sunburnt in less than 1/2 hour. I have also noticed the effects on vegetation here. I know my comment is not scientific, but you just need to ask a few people around here & there's general consensus. I couldn't figure out what was going on until they finally published that there was a hole in the ozone layer. Why we feel the effects despite us not being directly under the hole beats me, but it is noticeable.
I will unload my memory a little to give you a bit of info. Hope I get my facts right - it's about 18 years ago when I worked on a machine writing a Basic+ compiler for it.
The word size was 48 bits with a 3 bit tag for each word. Address size of the basic architecture was I think 20 bits which was defined mainly by the array descriptors which contained size & length of 20 bits plus 8 bits of other info. I think later versions virtualized the address space by adding some kind of virtual paged memory, but don't quote me - I didn't have much to do with that side.
The important feature was the tagged memory. With 3 bits, you could tag your data down to the individual word level. From my fading memory there were the following word types.
- 48 bit real (which also represented integer data - precision escapes me)
- Double precision real (96 bits) (the two words had to be contiguous)
- a procedure control word
- an indirect reference word
- an array descriptor
and 3 more which I can't remember - probably other kinds of descriptors. I seem to recall two kinds of array descriptors, there was a special coding for interior pointers (string pointers).
Also I believe there was a stack control word - to manage what we now call structured error handling. I find it hard to dig up much on the web about it, but there's probably a few books out there. I found this..
http://www.ajwm.net/amayer/papers/B5000.html
The processor was rather clever in the way it did things. Say you loaded a value from a location that was a procedure control word - it would go execute the function it pointed to and return the value - rather neat for algol thunks. Also if you hit an indirect reference word it would recursively load the data it pointed at.
Also, because it was a stack architecture, most of instructions were 1 byte long - only a handful were two bytes or more which made for very simple instruction decoders. All the hard work was done by interpretation of the tagged data - the microcode is what did all this. You could actually write a program by configuring your data in the right kind of way.
Why I see it relevant to Java is that one of the banes of java is effective garbage management. With tagged data, this job would be made easier, and also the hardware type checking would relieve the interpreted/compiled code somewhat. With the trend towards more object oriented languages and polymorphism, hardware type checking is what is really needed to make such languages execute efficiently.
Clearly, the word size and so forth is a bit antique, but the basic concepts might be valuable.
I don't know a lot about CISC -> RISC optimization, but my guess is that the stack model carries quite a lot of implicit information and a CISC->RISC scheduler might be able to do quite a good job of it, especially since the set of interpretable opcodes is quite small in comparison to register machines.
I guess what I'm trying to get at is that modern languages like java and C++ are pushing the limits of register architecture machines. It's very much like the difference between Fortran and Algol in the early days. The fortran machines just couldn't cut it with languages like Algol or PL/I. Just think, they had no concept of a stack as procedures weren't reentrant (typically the return address was stored in a global location).
It was a slow and unreliable old beast, but it was a marvel from a computing scence point of view. I find it sad that the nuts & bolts people have dictated the way computing has headed over the past 20 years - perhaps the reason why AI hasn't taken off like it should. The year 2001 is looming and we haven't got any semblance of a HAL with us, and won't do for at least another decade or more.
You comment about JIT compilers and such, but miss the point. The JVM is already a stack architecture - perhaps by adopting the data tagging techniques, and implemeting the JVM in silicon, one could get a rather powerful beast that doesn't require JITing. The tagging is important to distinguish a class reference from data, especially in local variables which have a tendency to be reused. Also, don't try to confuse system/heap management with normal execution. Some kind of mode/privelege switch could assist easily in those kind of house keeping activities.
I've recently gotten some feedback from fairly large real projects done in java, and a constant theme comes out of them which is that Java doesn't manage heaps particularly well. Throwing memory at the machine doesn't seem to help especially when you have a constantly changing data set - eventually you hit the working set size and things grind down to a halt.
I think we could do well to revisit some of the older architectures to see if they offer techniques that might lend themselves to modern programming.
I've followed the IA-64 for a while. I would have to agree that it is an entirely new beast which will take longer to develop good compilers for. The x86-64 design I have just checked up on.
You have to think about what you want out of a 64 bit architecture. To me they are 64 bit addressing, and 64 bit data.
Both architectures are capable of 64 bit addressing as far as I can see (actual implementations will probably be limited e.g. the initial AMD chip will initially be 48 bits of virtual address space I believe). How each handles the moving those addresses around will be critical to performance.
The major differences are in the handling of 64 bit data. The AMD chip extends the existing size of the registers to 32 bits and adds another set of 8 registers. The Intel one on the other hands supplies *heaps* of registers. While this would put the intel chip way in front, the downside is loading & storing registers when you change stack frames (calling a function). The rotating register stack helps, but eventually nesting of procedures can result in register spill. In some ways, the IA64 resembles a stack machine, but that's a dirty word these days - perhaps the terminology was avoided for those reasons.
Having written compilers over the years, I can definitely say that the i386 has suffered a severe shortage of registers. It's not a lot better than the pdp-11 (8 registers, 1 of which was the PC). As a result of this shortage, most languages run like a dog on the x386. They were even worse with the x86 because registers were dedicated to specific activities. It's also probably a good reason why cache performance has always been critical to getting i386 working well.
Having looked at both, my money will probably be with the AMD solution as it is an incremental design, not a revolutionary change. This affects the amount of work required to port existing code bases (OS core and compilers) to 64 bits. For example, my own OS could probably be ported relatively quickly to x86-64 much more quickly than with IA64.
Eventual performance differences will probably depend on the languages implemented and the programming styles applied. In my opinion, 16 general purpose registers is probably about as many that a good optimizing compiler would need for the typical C functions.
What both chips promise is the 64 bit addressing. This opens up a new realm for OS design because it allows disks and other structures to be mapped directly into the kernel's virtual address space. This is currently not possible with the current 4G limit because already storage devices are surpassing this limit. It is about time that CPU address space exceeded that of storage as it will allows for more elegant solutions to caching, disk management and swapping.
In the long run though, a new architecture is needed. Computing is likely change signiicantly in the next 10 years with the development of AI and better ways of using computer power. Given this, the IA64 might be the one which wins out in the long run because of the totally different view of execution. It does however assume that we finally make a break from the curse of legacy computing.
Personally, I am sad to see the stack architectures like the b6000/7000 series from Burroughs (now Unisys) die. They were incredible marvels of computer engineering that were at least a decade ahead of the register architecture machines. I especially liked the concept of tagged data which enabled the software to do rather marvellous things. Just the kind of machine that could run Java quite well. It is rather curious to see the trend from highly CISC machines to progressively more RISC machines, with the burden being placed more heavily on good compiler design. Consistent with this approach, IA64 looks to be a machine that will be tightly bound to specific compiler optimization techniques, although this bothers me a little because very likely those with access to the best compilers will be the ones who get the best performance out of these beasts. Compaq because of the inherited Digital resources would have access to some of the best compiler technology on the planet. It is widely recognized that the original Bliss compiler was state of the art by miles when Digital developed it in the 70's.
While some say/48 will be the minimum allocation, that's for a whole site. More than likely the absolute minimum that a transient (dialup, DSL) customer will get will be a/64. Even so, that does leave a full 64 bits to play with, and IPv6 address space has been configured with that in mind. What this means is that almost every LAN segment will have roughly 64 bits to play with.
In IPv6, the upper 64 bits are designated for routing, the lower 64 bits for node addresses. In theory, you can route within those lower 64 bits, but it is more likely that people will utilize space just above the 64 bit mark as it will make a lot more sense for routers to manage the address space that way. So I predict that customers needing to set up a routed network will most likely receive an address range
IPv6 will significantly change the way that people will think about their local networks. Why do NAT unless you absolutely have to. Give me good reasons why a NAT is necessary. I don't buy the argument that it's a good firewall - the reality is that it isn't, as I have been told by industry experts. At best, it is a "poor man's firewall", more things break than is necessary. It's high time we did more about individual security on hosts rather than relying on the somewhat dubious security features that NAT delivers. A real firewall may resemble a NAT, but in practice is significantly more fortified than the average NAT box.
The original topic of this whole issue is that NAT breaks end-end connectivity. It really should be outlawed, and IPv6 provides the opportunity.
It's generally recognized that NATs are a hack to get around the failing of the current IPv4 network. Even though I have written one of the first NATs before they became popular, it is widely agreed within the IETF that NATs present surmounatble problems. In adition to the inability to establish peer to peer TCP connections - the primary reason being that you can't determine both ends TCP ports until after the connection is established - there are also significant problems for network security mainly because you can't directly ties the end user's IP address to the security protocol. Also, IPsec won't work through NAT's particular well because the ESP protocol doesn't typically work through NATS. Also, I suspect that MTU discovery may not fully work through NATs if they haven't been correctly implemented - i.e. you also need to translate the ICMP messages related to the NAT - often these might not pass through.
This is one of the dominant reasons why IPv6 is needed. While there are many reasons that NAT is useful, the dominant one is the lack of IP addresses. Ipv6 certainly deals handsomely with that issue.
Another issue I have with NATs is that from an ISP point of view (we run one also) it is quite difficult to trace a rogue user that is on the inside of a NAT because usually a NAT will hide the identity of the customer, and you have to resort to other means to determine the identity of a user that may be launching an attack. This may be a good thing for some, but generally it makes life more difficult for the sysadmin.
There are other failings with NATs - for that reason they are generally frowned upon.
remarkably, I actually saw this lecture live (delayed??) the other night broadcast by the ABC. It was quite a bombshell, especially the jibes about the MD of the ABC. Embarassingly, the author kept saying apologetically he wasn't trying to be personal. I don't think the listeners were that convinced. Especially poignant when the MD had to actually respond to the lecture after it was given. Quite a bunfight.
The following comment stuck out in my mind, because it flies in the face of most editorial comment about the Internet that one typically hears in Australia, even the ABC.
"Most of the dot-coms that were created and funded handsomely to deliver journalism are now struggling or defunct. Even the best American examples, such as Salon, Slate and The Street.com, are either running out of money or seem to have no prospect of making journalism a viable Internet proposition, or both."
I personally agree, and have seen the continual devaluation of just about anything that the Internet has to offer, not just journalistic content.
It would seem that the expectation is that if something is delivered over the internet, it should be free, and by implication if it's free, then it's not really worth much. This is especially relevant to much of the free software that can currently be obtained via the internet.
I see parallels from what was said about the quality of journalism and the quality of software. In the same way as good journalism is expensive and requires very skilled and experienced manpower, I believe that good software is also expensive to build and maintain, and requires a similar degree of expertise. In my opinion, open source has the failing of not being underpinned by a strong commercial basis, and as a result suffers from quality control and lack of a strong visionary sense of direction.
I know I am regarded as reactionary as far as the open source movement is concerned, but alas, I find it hard to be silent when I see an industry possibly heading in a direction that devalues software.
In the same breath however, I am also disgusted at the excesses and manipulation that exist in the larger corporate software companies that also do little to forge new directions for the industry as a whole, and there are parallels here between journalism and software.
Finally, I also see a parallel in terms of control. In the same way that the control of journalistic content is being used to manipulate society, I can see in the next few decades that those who control the software will also control society in their own way.
Why not have slashdot run a proxy web server like squid and then point all the URL's to this rather than to the actual web sites in question.
Of course, then you'd lose the one thing that sets slashdot apart from its competitors. Some other parts of the IT community regard being slashdotted as having some prestige value.
Given that most CPU's would have some kind of firmware that is most likely proprietary, the Free Software Movement might have a job being able to actually build a fully free system according to their tenets of faith.
Or put another way, how can one realistically build a completely free computer system. There are most likely many components of a modern computer system that would have proprietary software built in, or that have been designed with proprietary software.
I think the whole issue is a bit of a giggle really.
We have metered by the meg for years because our suppliers meter us - we have no choice. And get this, the list rate for wholesale in Aus for a small ISP is around AU$0.14-0.19 per meg. Of course you can get better deals than that if you shop around and sign anti competitive NDAs, but not much better, certainly not what it costs in the US. Typically a customer in Aus pays between 10-20 times as much as the same customer in the US.
Typically ISPs here deal with it in three ways..
1) directly charge the customer per meg.
2) factor the average megs into an hourly rate.
3) apply download quotas on all you can eat accounts in various ways.
Either way, it has totally screwed up the market here in Aus.
Having personally spoken directly to the current CEO of Australia's largest Telco (and ISP) who supply wholesale to a large chunk of the market, the word is that that's the only way they can recoup the huge cost to plug into the US backbone, carry traffic across the Pacific and then deliver it around Aus. This is the same company that makes billion dollar profits every year without fail. All the other capable telcos just follow suit and so in general the public is being screwed by such schemes.
I can tell you it sucks.
Technical details...
We have a sophisticated RADIUS based usage tracking mechanism which feeds into an SQL database through to a rules based billing system. And if our system as much as sneezes, the customers are down our throats wanting refunds. The worst is when they are unware that their connection is slowly draining their quota even when they aren't apparently doing much. Imagine the financial pain when an ISP get smurfed.
Slashdot Mirror
He is not suing anyone. Not everything involves someone getting sued. No-one is getting sued here.
Why else would you need amnesty? Why else would he be extending "amnesty" only until a certain date? Which, by the way, is not amnesty. It's a grace period. Hope this helps.
call it what you will, just a gesture to remove any doubt people might have over possible infringement. copyright rules can also vary internationally. I just set an arbitrary date. I will most likely extend it on a rolling basis after that date. there are no plans to sue anyone!
Yeah, I thought you'd get a giggle out of that... perhaps I should have made it 12th Dec, 2012 ;)
just for the record folks... I just posted this in response...
"urban myth. the only court case was the one with Ozemail, cited in the original thread. It cost both sides heaps to run the case and was settled out of court after the judgement was given. Trumpet Software did receive some $$$, but not on the scale you mentioned."
As for starting up, Trumpet Software grew out a lounge room from shareware regs alone, not with a huge cash injection from a court settlement or any VC $$$.
As for some of the other stuff, there's a fair bit of personal stuff which would be inappropriate for me to discuss, except it almost broke me to have to resign my position in the business in 2004 because of the divorce proceedings. There are also some other inaccuracies in the statements you made, but as you can understand it is just not appropriate for me to discuss the ugliness of the divorce proceedings and settlement in public (except to say it took almost 7 years through the courts, the longest case in Hobart I have been told).
Peter T
What would be great is if Intel exposed their RISC instructions so that you could run it like a true RISC. Maybe there are already secret backdoors which would allow you to do this - some instruction to make it jump into RISC mode. Anyone got any ideas on this?
P
Should be retitled "HAZARDS OF BEING A PUBLIC FIGURE"
Since you leave me no choice but to answer the allegations in a public forum, here goes. Unfortunately this will will make me seen as a Linux or Unix basher which I am not.
I do recall being harassed by a couple of Linux zealots at a public meeting as usually happens.
I remember a conversation with someone which is roughly consistent with what you say except for a couple of points. I don't publicly use phrases like "xyz is shit" and "that's bullshit". I might speak in such terms among close friends but not to members of the public. If you don't have a tape recorder to back up your allegations, stop lying - it does your case no good.
I know this whole thing is fabricated because you say we use redhat linux in our organization. We have not ever and never will uses Linux for anything. I think it may have been installed once by an employee on their own personal hardware for a specific purpose (gaming server?) but that is the extent of how far Linux has ever made it into our place. It was removed when the employee fled the state seeking a "better" life.
The conversation if I remember rightly went similar to this but I can't remember anything word for word, it's too long ago. I will just dot point. The order of topics discussed may all wrong, but I will cover the issues you have raised.
- someone probes me about our OS which we've just announced in July 99. I only respond with what I am publicly prepared to disclose. I talk about the OS and what it is capable of at that time. explain that I can bring up a full internet server, 32 bit OS running from a single floppy, native and it comes up in a flash. This seems to fly over their head or the achievement otherwise ignored. They also seem to be amused at our apparent lack of progress.
- they are trying to make me look like an arsehole by trying to catch me off guard so I begin to be defensive. seems like they have an axe to grind.
- its clear they have a closed mind about all OSes apart from free ones, in particular Linux.
- they ask me about wine. I give an honest opinion - at that time I most likely say one of two things.. it depends on when the meeting took place which the person isn't willing to disclose.
Either I am aware of wine at this stage and say that
a) yes, I know of wine I say that wine is certainly more advanced than we are, but that I feel a direct approach at OS integration is better. I also express that wine has been taking a long time to achieve its target. They misinterpret my criticism. I probably raise anumber of ciritcisms but I honestly can't remember much more.
or
b) I am not aware of wine - tell me more - news to me, etc.
I'm fairly sure I was very aware of wine and its state of play at around Jul 99 so I think answered a) I can say there was a point at which I was alerted to wine by someone to which I may have been surprised or couldn't respond because of lack of
- they ask me about unix. I say I have nothing against unix, but that the IT world is bigger than Linux and Unix. They think I'm talking rubbish and can't believe anyone would not think that Unix & Linux are the best OS's in the world. I talk about why we shouldn't lock oursleves down with 70's technology and try to express some technical thought about why unix has inefficiencies and design flaws that make it not the best choice for the general public. I talk about how Joe everage doesn't give a hoot about unix and would have grave difficulties trying to install unix. I try to raise many of the other general criticisms about trying to force unix on the general public won't work. Again I seem to be talking to the walls.
- at some point the discussion over why I don't use Linux is raised. I probably point out that we use FreeBSD in house and for good reason. I prefer an OS with a pedigree. It's difficult for me to put into words what I have observed of Linux over the years and its process of development which makes me unwilling to trust it as a mission critical OS. I most likely express it by saying that I don't believe Linux is stable enough for our requirements. Very likely I again failed to get my point across.
- the issue of why I am even bothering with Windows emulation is raised through the discussion. I talk about what most of the industry is using and that asking people to switch to Linux or Unix to do their work is impractical.
I am sadly and deeply hurt by this public attack on my credibility, especially in my own home town.
If people like you got their way, I would turn my back on the whole industry. I am capable of doing other things and life is too short to squeeze them all in.
In a true Australian and especially Tasmanian tradition any success we have had has been flushed down the toilet because of the petty jealousy that runs rife in our town and the whole country. Classic tall poppy syndrome.
Face it, Tasmania is an IT backwater and will remain so until those in the industry learn to build each other up rather than tear down every achievement ever made. I have said this many times in Hobart and have been hated for it. This attack just adds weight to my argument.
As for your other comments about the way we run our business - we have a reputation for not being a pushover - you either shape up or ship out. It's a small town and gossip abounds when staff are encouraged to leave for whatever reason. That is a harsh reality in the modern business world. If you only knew the truth of what the business and employment community has done to us in Hobart you would swallow your words. Unfortunately I cannot discuss such things in public as some are pending criminal action.
For others reading this, you may think I am a fool for even responding to this troll. I have responded for your benefit so that you can see the level of hardship and personal attack that anyone of prominence goes through when trying to achieve their dream.
Peter
And so I should answer these allegations or not?
Perhaps you are frustrated that I *haven't* attended a Computer Society meeting for over 4 years as...
1) I'm not a member of the ACS.
2) Despite repeated requests for me to speak at a ACS meeting in Hobart, I've been too busy working on the OS to spare the time plus I have a busy company to run.
I'm sure those in the ACS branch in Hobart would be appalled to hear one of their members refer to me in such a manner. Like me to follow it up?
Peter R. Tattam
I have been involved in the multihoming debate for a couple of years now. I haven't gotten into the multi6 group yet for reasons of time, but I have already submitted a novell idea at an interim IETF meeting on the issue, which was well received. The ideas need to be progressed towards an I-D, but again time contraints slow me down. My idea centred around a mechanism for hosts to dynamically change the IPv6 address for active TCP connections with only minor enhancements to the IPv6 and TCP layers. The same idea can be extended to other protocols and is also backward compatible with existing Ipv6 infrastructure.
The whole point is that its impossible to route a very large network by meshing large numbers of nodes or networks in one location. Eventually the thing won't scale if you allow indiscriminate DFZ explosion. Even labeling (MPLS) will die when the network gets too big.
Hierarchical table management is the way to deal with it. The Ipv6 solution to the multihoming problem is to assign multiple network addresses. Packet delivery for at least one of those networks can be guaranteed under that scenario so the network infrastructure is certainly doing its job. It's up to the higher layer protocol designers to figure out how they should deal with hosts having multiple addresses and then the problem is licked.
If you consider that multihoming information is much longer lived than perhaps mobile IP, the solutions for dealing with the multiple addresses start to fall in place.
Perhaps its time I got back into the multi 6 debate again and get the issue resolved - I have to admit its the bugbear of Ipv6 deployment at the moment.
Having written a NAT, I know a little bit about what I'm talking about.
Study up on IPsec/IKE, and you'll find that having live unique Ip addresses at each end is essential to the security model. NAT breaks this.
As for the server stuff - yes it probably can be done, but how do you handle several web servers, all through a single IP address and the same public port 80. You have to choose another public port which then will start to break other things (e.g. routing filters), or decode the TCP data to attempt to work out where the stream is destined. You can probably do it by inspecting the data streams and directing traffic as appropriate, but this won't scale to large networks... too much CPU required.
As for FTP or any other protocol that passes IP addresses in the TCP stream, the NAT box has to decode the data and modify it in a protocol dependent manner. Ok for a small NAT newwork, but prohibitive in a large network. But for similar reasons above won't scale.
It would be a trivial matter for a CD ripper to validate the resulting rip to make sure it didn't do stupid things like signals that blow up speakers and such. It would just make the rip slower that's all.
Sounds like a whole bunch of FUD to me.
Not that I'm in favour of ripping CD's mind you. The poor musician is one who really gets screwed (after already being screwed by the recording companies).
1. Ipv4 Address space is sufficient?
wrong. There are large chunks of the world that can't get address space to do what they want. Especially Asia which is only now starting to get into the Internet. it is also estimated that giving every mobile phone over the next 10 years or so an IP address will also make us run out of addresses.
2. NAT is the answer? No, for true secure internet you need end to end connectivity. This means live IP addresses, not hiding behind NAT. Also NAT can't pass everything through. e.g. try to pass ESP for several devices through NAT. Also try to run several independent servers of the same service type (e.g. web sites) behind a NAT. Gets very difficult.
3. Routing for Ipv6 will fall apart because of the large routing tables?
Wrong. The way strong aggregation is defined in Ipv6 results in the Default Free Zone (DFZ) of the core internet being very small (designed to be < 8000 or so entries). That same aggregation policy applies to for TLA (top level aggregate), NLA (next level aggregate) and SLA (Site level aggregate). If people adhere to the rules, there will be no routers blowing up any time soon. Router lookups will be faster than they have ever been because of the strict aggregation boundaries.
As an aside, Ipv6 does not have a header checksum so routers will no longer need to checksum all headers as they pass through. This will also reduce router processing overhead.
To qualify (3) I must add that multihoming is done differently in Ipv6. No site will ever "own" their address space so it can never be advertised into the DFZ. This is the mistake that we learnt from IPv4. To multihome you will be required to have an address space from each provider (SLA/NLA or TLA) that you are multihoming to. This means that nodes in a multihomed site will potentially have more than one visible address on the internet to maintain connectivity. The details of how to deal with the multiple address issue are in the process of being sorted out, but I can assure you there are several solutions to the issue of multihoming in Ipv6.
4. Privacy is gone in Ipv6. (in case anyone wants to raise the point).
This has been debated before about the issue of your NIC address being publicized. It is a simple matter to anonymize the address and an I-D has already been done to deal with this.
So Ipv6 is not DOA as some would suggest. It's only a matter of time before people realize that it's absolutely required for the Internet to move forward.
Do your research and you'll find that Ipv6 is needed and will make life on the internet much more saner. The availability of reasonable address space is the fundamental one, and I'm sure the IAB/IETF can bring enough pressure to bear on providers to make sure everyone gets a fair share of this address space. Don't also forget that it's a free market - giving adequate address space can be a selling point for a competitive ISP.
...would be my bet ;)
Found it hard to find an appropriate title for this post, but hopefully others can get my drift.
I find it amazing that given the considerable understanding of economic monetary systems and the value of production etc. in these forums, that there is a lack of perception of the impact that open source software (in particular free software) is having on the software industry, and even the online industry as a whole.
There are two issues...
1) collective ownership of the software. Nobody has to pay for it, assigning an intrinsic exchange value of $0 for the software. There are hidden costs in "mining" the software (ISP costs, cost of storage and other infrastructure), but these are neglible in comparison to the true worth of a utility.
2) virtually unlimited replication. You create as many instances as your "warehouse" can contain. Sort of like printing your own money when you need more. This is the stuff of inflationary monetary policy.
Both of these factors effectively reduce the value of the software to the point where it becomes uneconomic to invest resources into creating better software, eventually stifling innovation. It's really an experiment in communism. At the moment, the open source movement is basking in the euphoria that usually accompanies such a revolution, but such euphoria won't last forever.
However, I believe that history will show itself in the future with the result that open source will suffer the demise of that of any economy based on collective ownership - it may be 5 years, or it could be 50. I guess it will take around 2-3 "generations" as I suspect it has a lot to to with social engineering - the zealots start the movement, the masses reap the short term benefits, the later generations reap the damage caused.
In the meantime, we might go through a period of "dark age" mentality because true innovation of software remains unrewarded due to the devaluation of software's true worth.
The sad thing is that I believe that large companys like Microsoft fully understand the economic principles behind open source, and are secretly embracing it and encouraging it to grow. It can only increase their hold on the software industry by the removal of smaller innovators like ourselves, and in the long run, they will be the Barons of the future.
You're playing right into their hands folks.
I can remember a time when I didn't get spam & my email adress was public on the NNTP feeds.
ok. thanks for the clarification.
I guess the firewalls/routers have their own reasons for rejecting such packets. The reality is that ECN in the spirit of not breaking backward compatibility should be able to work around these scenarios. It current;y doesn't which is why I suggest it needs to be sent back to the drawing board.
My suggestion is to try ECN first, if a RST is encountered, try again without ECN and mark the path as ECN unfriendly. If the firewall is dropping packets, then perhaps alternate TCP SYN's between ECN & non-ECN packets until a connection is established or timeout.
It is not a solution to insist that the errant routers/firewalls be replaced. The may have very good reasons for their paranoid rules and in many cases it may be impractical to perform an upgrade.
Consider also the case where the reserved TCP bits might be in use locally in a site for traffic management (perhaps in error). site policies might mandate that exploits using these bits be terminated ASAP.
Anyway, my main gripe is that the solution to the scenarios is not to fix the routers/firewalls, but to implement better workarounds in the protocol itself. The appropriate and well tested method of extending protocols like TCP is through header options, and not by manipulating the reserved bits.
P
I think the real problem is that ECN makes some wild assumptions about which bits in the headers to use. The Ipv4 TOS byte is overloaded to blazes. Bad idea to use that as it should have been considered no man's land, and there appears to be no escape mechanism to negotiate behaviour between two hosts.
Had I done this, I would have added the extra bits elsewhere... perhaps TCP header extensions.
Hint to implementors. I would attempt to see if a clear path exists for those bits to work before applying it to a circuit.
As I said before I think that the protocol is broken because the discovery mechanism is unreliable as we have now seen.
Time to go back to the drawing board folks...
You can be sure we are taking note.
The very monopoly that MS think they have might be their downfall when alternative OS's come to market.
We will certainly be able to offer very cost effective site licenses for PetrOS(tm) when the wincompatibility is finished.
Peter
As someone who lives close to this hole (Tasmania, Australia), I have noticed the change for myself. I hope they are right because I am sick of getting sunburnt in less than 1/2 hour. I have also noticed the effects on vegetation here. I know my comment is not scientific, but you just need to ask a few people around here & there's general consensus. I couldn't figure out what was going on until they finally published that there was a hole in the ozone layer. Why we feel the effects despite us not being directly under the hole beats me, but it is noticeable.
I will unload my memory a little to give you a bit of info. Hope I get my facts right - it's about 18 years ago when I worked on a machine writing a Basic+ compiler for it.
The word size was 48 bits with a 3 bit tag for each word. Address size of the basic architecture was I think 20 bits which was defined mainly by the array descriptors which contained size & length of 20 bits plus 8 bits of other info. I think later versions virtualized the address space by adding some kind of virtual paged memory, but don't quote me - I didn't have much to do with that side.
The important feature was the tagged memory. With 3 bits, you could tag your data down to the individual word level. From my fading memory there were the following word types.
- 48 bit real (which also represented integer data - precision escapes me)
- Double precision real (96 bits) (the two words had to be contiguous)
- a procedure control word
- an indirect reference word
- an array descriptor
and 3 more which I can't remember - probably other kinds of descriptors. I seem to recall two kinds of array descriptors, there was a special coding for interior pointers (string pointers).
Also I believe there was a stack control word - to manage what we now call structured error handling. I find it hard to dig up much on the web about it, but there's probably a few books out there. I found this..
http://www.ajwm.net/amayer/papers/B5000.html
The processor was rather clever in the way it did things. Say you loaded a value from a location that was a procedure control word - it would go execute the function it pointed to and return the value - rather neat for algol thunks. Also if you hit an indirect reference word it would recursively load the data it pointed at.
Also, because it was a stack architecture, most of instructions were 1 byte long - only a handful were two bytes or more which made for very simple instruction decoders. All the hard work was done by interpretation of the tagged data - the microcode is what did all this. You could actually write a program by configuring your data in the right kind of way.
Why I see it relevant to Java is that one of the banes of java is effective garbage management. With tagged data, this job would be made easier, and also the hardware type checking would relieve the interpreted/compiled code somewhat. With the trend towards more object oriented languages and polymorphism, hardware type checking is what is really needed to make such languages execute efficiently.
Clearly, the word size and so forth is a bit antique, but the basic concepts might be valuable.
I don't know a lot about CISC -> RISC optimization, but my guess is that the stack model carries quite a lot of implicit information and a CISC->RISC scheduler might be able to do quite a good job of it, especially since the set of interpretable opcodes is quite small in comparison to register machines.
I guess what I'm trying to get at is that modern languages like java and C++ are pushing the limits of register architecture machines. It's very much like the difference between Fortran and Algol in the early days. The fortran machines just couldn't cut it with languages like Algol or PL/I. Just think, they had no concept of a stack as procedures weren't reentrant (typically the return address was stored in a global location).
It was a slow and unreliable old beast, but it was a marvel from a computing scence point of view. I find it sad that the nuts & bolts people have dictated the way computing has headed over the past 20 years - perhaps the reason why AI hasn't taken off like it should. The year 2001 is looming and we haven't got any semblance of a HAL with us, and won't do for at least another decade or more.
You comment about JIT compilers and such, but miss the point. The JVM is already a stack architecture - perhaps by adopting the data tagging techniques, and implemeting the JVM in silicon, one could get a rather powerful beast that doesn't require JITing. The tagging is important to distinguish a class reference from data, especially in local variables which have a tendency to be reused. Also, don't try to confuse system/heap management with normal execution. Some kind of mode/privelege switch could assist easily in those kind of house keeping activities.
I've recently gotten some feedback from fairly large real projects done in java, and a constant theme comes out of them which is that Java doesn't manage heaps particularly well. Throwing memory at the machine doesn't seem to help especially when you have a constantly changing data set - eventually you hit the working set size and things grind down to a halt.
I think we could do well to revisit some of the older architectures to see if they offer techniques that might lend themselves to modern programming.
I've followed the IA-64 for a while. I would have to agree that it is an entirely new beast which will take longer to develop good compilers for. The x86-64 design I have just checked up on.
You have to think about what you want out of a 64 bit architecture. To me they are 64 bit addressing, and 64 bit data.
Both architectures are capable of 64 bit addressing as far as I can see (actual implementations will probably be limited e.g. the initial AMD chip will initially be 48 bits of virtual address space I believe). How each handles the moving those addresses around will be critical to performance.
The major differences are in the handling of 64 bit data. The AMD chip extends the existing size of the registers to 32 bits and adds another set of 8 registers. The Intel one on the other hands supplies *heaps* of registers. While this would put the intel chip way in front, the downside is loading & storing registers when you change stack frames (calling a function). The rotating register stack helps, but eventually nesting of procedures can result in register spill. In some ways, the IA64 resembles a stack machine, but that's a dirty word these days - perhaps the terminology was avoided for those reasons.
Having written compilers over the years, I can definitely say that the i386 has suffered a severe shortage of registers. It's not a lot better than the pdp-11 (8 registers, 1 of which was the PC). As a result of this shortage, most languages run like a dog on the x386. They were even worse with the x86 because registers were dedicated to specific activities. It's also probably a good reason why cache performance has always been critical to getting i386 working well.
Having looked at both, my money will probably be with the AMD solution as it is an incremental design, not a revolutionary change. This affects the amount of work required to port existing code bases (OS core and compilers) to 64 bits. For example, my own OS could probably be ported relatively quickly to x86-64 much more quickly than with IA64.
Eventual performance differences will probably depend on the languages implemented and the programming styles applied. In my opinion, 16 general purpose registers is probably about as many that a good optimizing compiler would need for the typical C functions.
What both chips promise is the 64 bit addressing. This opens up a new realm for OS design because it allows disks and other structures to be mapped directly into the kernel's virtual address space. This is currently not possible with the current 4G limit because already storage devices are surpassing this limit. It is about time that CPU address space exceeded that of storage as it will allows for more elegant solutions to caching, disk management and swapping.
In the long run though, a new architecture is needed. Computing is likely change signiicantly in the next 10 years with the development of AI and better ways of using computer power. Given this, the IA64 might be the one which wins out in the long run because of the totally different view of execution. It does however assume that we finally make a break from the curse of legacy computing.
Personally, I am sad to see the stack architectures like the b6000/7000 series from Burroughs (now Unisys) die. They were incredible marvels of computer engineering that were at least a decade ahead of the register architecture machines. I especially liked the concept of tagged data which enabled the software to do rather marvellous things. Just the kind of machine that could run Java quite well. It is rather curious to see the trend from highly CISC machines to progressively more RISC machines, with the burden being placed more heavily on good compiler design. Consistent with this approach, IA64 looks to be a machine that will be tightly bound to specific compiler optimization techniques, although this bothers me a little because very likely those with access to the best compilers will be the ones who get the best performance out of these beasts. Compaq because of the inherited Digital resources would have access to some of the best compiler technology on the planet. It is widely recognized that the original Bliss compiler was state of the art by miles when Digital developed it in the 70's.
While some say /48 will be the minimum allocation, that's for a whole site. More than likely the absolute minimum that a transient (dialup, DSL) customer will get will be a /64. Even so, that does leave a full 64 bits to play with, and IPv6 address space has been configured with that in mind. What this means is that almost every LAN segment will have roughly 64 bits to play with.
In IPv6, the upper 64 bits are designated for routing, the lower 64 bits for node addresses. In theory, you can route within those lower 64 bits, but it is more likely that people will utilize space just above the 64 bit mark as it will make a lot more sense for routers to manage the address space that way. So I predict that customers needing to set up a routed network will most likely receive an address range
IPv6 will significantly change the way that people will think about their local networks. Why do NAT unless you absolutely have to. Give me good reasons why a NAT is necessary. I don't buy the argument that it's a good firewall - the reality is that it isn't, as I have been told by industry experts. At best, it is a "poor man's firewall", more things break than is necessary. It's high time we did more about individual security on hosts rather than relying on the somewhat dubious security features that NAT delivers. A real firewall may resemble a NAT, but in practice is significantly more fortified than the average NAT box.
The original topic of this whole issue is that NAT breaks end-end connectivity. It really should be outlawed, and IPv6 provides the opportunity.
It's generally recognized that NATs are a hack to get around the failing of the current IPv4 network. Even though I have written one of the first NATs before they became popular, it is widely agreed within the IETF that NATs present surmounatble problems. In adition to the inability to establish peer to peer TCP connections - the primary reason being that you can't determine both ends TCP ports until after the connection is established - there are also significant problems for network security mainly because you can't directly ties the end user's IP address to the security protocol. Also, IPsec won't work through NAT's particular well because the ESP protocol doesn't typically work through NATS. Also, I suspect that MTU discovery may not fully work through NATs if they haven't been correctly implemented - i.e. you also need to translate the ICMP messages related to the NAT - often these might not pass through.
This is one of the dominant reasons why IPv6 is needed. While there are many reasons that NAT is useful, the dominant one is the lack of IP addresses. Ipv6 certainly deals handsomely with that issue.
Another issue I have with NATs is that from an ISP point of view (we run one also) it is quite difficult to trace a rogue user that is on the inside of a NAT because usually a NAT will hide the identity of the customer, and you have to resort to other means to determine the identity of a user that may be launching an attack. This may be a good thing for some, but generally it makes life more difficult for the sysadmin.
There are other failings with NATs - for that reason they are generally frowned upon.
Time to rollout IPv6.
remarkably, I actually saw this lecture live (delayed??) the other night broadcast by the ABC. It was quite a bombshell, especially the jibes about the MD of the ABC. Embarassingly, the author kept saying apologetically he wasn't trying to be personal. I don't think the listeners were that convinced. Especially poignant when the MD had to actually respond to the lecture after it was given. Quite a bunfight.
The following comment stuck out in my mind, because it flies in the face of most editorial comment about the Internet that one typically hears in Australia, even the ABC.
"Most of the dot-coms that were created and funded handsomely to deliver journalism are now struggling or defunct. Even the best American examples, such as Salon, Slate and The Street.com, are either running out of money or seem to have no prospect of making journalism a viable Internet proposition, or both."
I personally agree, and have seen the continual devaluation of just about anything that the Internet has to offer, not just journalistic content.
It would seem that the expectation is that if something is delivered over the internet, it should be free, and by implication if it's free, then it's not really worth much. This is especially relevant to much of the free software that can currently be obtained via the internet.
I see parallels from what was said about the quality of journalism and the quality of software. In the same way as good journalism is expensive and requires very skilled and experienced manpower, I believe that good software is also expensive to build and maintain, and requires a similar degree of expertise. In my opinion, open source has the failing of not being underpinned by a strong commercial basis, and as a result suffers from quality control and lack of a strong visionary sense of direction.
I know I am regarded as reactionary as far as the open source movement is concerned, but alas, I find it hard to be silent when I see an industry possibly heading in a direction that devalues software.
In the same breath however, I am also disgusted at the excesses and manipulation that exist in the larger corporate software companies that also do little to forge new directions for the industry as a whole, and there are parallels here between journalism and software.
Finally, I also see a parallel in terms of control. In the same way that the control of journalistic content is being used to manipulate society, I can see in the next few decades that those who control the software will also control society in their own way.
Why not have slashdot run a proxy web server like squid and then point all the URL's to this rather than to the actual web sites in question.
Of course, then you'd lose the one thing that sets slashdot apart from its competitors. Some other parts of the IT community regard being slashdotted as having some prestige value.
Given that most CPU's would have some kind of firmware that is most likely proprietary, the Free Software Movement might have a job being able to actually build a fully free system according to their tenets of faith.
Or put another way, how can one realistically build a completely free computer system. There are most likely many components of a modern computer system that would have proprietary software built in, or that have been designed with proprietary software.
I think the whole issue is a bit of a giggle really.
We also run an ISP...
We have metered by the meg for years because our suppliers meter us - we have no choice. And get this, the list rate for wholesale in Aus for a small ISP is around AU$0.14-0.19 per meg. Of course you can get better deals than that if you shop around and sign anti competitive NDAs, but not much better, certainly not what it costs in the US. Typically a customer in Aus pays between 10-20 times as much as the same customer in the US.
Typically ISPs here deal with it in three ways..
1) directly charge the customer per meg.
2) factor the average megs into an hourly rate.
3) apply download quotas on all you can eat accounts in various ways.
Either way, it has totally screwed up the market here in Aus.
Having personally spoken directly to the current CEO of Australia's largest Telco (and ISP) who supply wholesale to a large chunk of the market, the word is that that's the only way they can recoup the huge cost to plug into the US backbone, carry traffic across the Pacific and then deliver it around Aus. This is the same company that makes billion dollar profits every year without fail. All the other capable telcos just follow suit and so in general the public is being screwed by such schemes.
I can tell you it sucks.
Technical details...
We have a sophisticated RADIUS based usage tracking mechanism which feeds into an SQL database through to a rules based billing system. And if our system as much as sneezes, the customers are down our throats wanting refunds. The worst is when they are unware that their connection is slowly draining their quota even when they aren't apparently doing much. Imagine the financial pain when an ISP get smurfed.
bandwidth metering... hah.