"Contrary to some suggestions I have heard in connection with this case,
product integration is unambiguously good for consumers," Sanders testified
and then
He cited AMD's integration of memory-controlling functionality into its
upcoming Hammer microprocessor as an example of how companies integrate once-separate features into their products.
Wow, and AMD is sure to remember Intel's integration of a RAMBUS controller into it's Pentium 4, and how embarrising that was after Intel decided to rethink their strategy.
Could someone explain to me how choosing a particular technology for your customers and saying this is all you're allowed to use fosters competition?
The complaint about using grep + awk is just stupid. grep is significantly faster than awk, anyway.
Couldn't find where you were referencing this (guess it was in your link). In any case, I don't see where grep is shown to be "faster" than awk. I'm sure you know their respective purposes, but awk and grep use the same type of searching algorithm (DFA), so the only slowdown in awk is because it does more with each line (e.g. run the provided script). sed on the other hand (like perl) uses NFA (so as to do search/replace on the input stream), which is fundamentally slower.
# output of multiple executions instead of a single pipe (usually cmd-dependent)
cat file | cmd/dev/fd/0 # for when it simple MUST have a command-line argument file-name
cmd "adf${FOO}asdf\"dfdf\"sdfs"\ sdfs\ \,
cmd <<EOS here is my long text bla bla bla EOS
# quoting in general is MUCH better in *sh than what I've seen available on windows (not 100% sure about cmd.exe; please correct me if I'm wrong about it not have a fully encodble string command line) # side note, bash sucks compared to perl's string processor (e.g. qq(...) )
cmd1 ; ( cmd2 && cmd3 & ) || cmd4
# serialized, parallelized, and conditionally based command execution (not to mention sub-shelled)
nohup cmd
# disconnect from shell and log output (in case modem hangs up, or in more modern situations, the general terminal disconnects)
screen
# while not strickly the shell, the pseudo-terminal technology easily allows detachable / reattachable terminals
All the test commands (not quite sure how well cmd's scripting works)
alias ls funcion ls() {... } ls \ls which ls # multi-teered command-interpretations
ulimit # control resource consumption (granted this isn't a shell thing, but it's nice to do from the shell)
times # see my resource utilization (see ulimit for caveat)
jobs # and other such wonder background management tools (see above caveat)
Don't know if cmd.exe has file-descriptor modifications like [n]>&- (close descriptor n)
Then, there's my favorite.. emacs or vi-based low-bandwidth, high-productivity editor commands. A command is considered to be like a mini-program, so the editor treats the unlimited line-size as such.
Your argument is sound, and presumably arguable, up to your last step.
I agree that there are probably issues with my approach with the current law, however, compare this to software duplication; Microsoft even. MS acknowledges that for a system administrator it's tedious to man-handle thousands of OS/Office CDs, and thus only a master set is utilized and per-installation serial numbers are used.
Laws have to change with the times, and I refuse to sit still when the status quo is being argued.
At the very least, a form of secondary use licensing should be available, which is the right to use the digital media in other form, potentially originally derived from a CD, the web, etc. This would be adequate to allow an online site like mp3.com to consolidate binary images.
Even still, the argument that multiple digital images "might" allow simultaneous reuse (and thereby actualize duplication) doesn't mean it realistically will (e.g. single people that live alone like myself). That you currently can put an mp3 image on a portable player alone demonstrates the flaws in this logic. (Not that there wasn't all sorts of fear when this concept was first started).
Easy, if you know its illegal you shouldn't be doing it.:)
Someone at that company must have had broadband at home. Set up the server there and presto bingo! The likelyhood of it being the company's fault rather than your own just plummeted.
You're missing the point. You _are_ allowed to put your purchased CD in the CD-ROM drive-tray at work last I checked. From that, it's trivial to rip the CD and save the files locally so you don't have to bring your entire CD collection back and forth from home. It is beyond immoral for a company to tell you how to live your life (e.g. that you must carry your original CDs with you as you would an ID card (which so far is only enforced for visa's and drivers licences in special circumstances)).
Assuming that you agree with me thus far, then it is not too far of a stretch to fathom a personal archive of music at work on a work machine (much like you'd install your own background image, or heaven forbid, your own OS).
While company policy might restrict such use of a computer (e.g. a bank that disallows entry/departure of data/files), most aren't this strict.
A company that encourages a "happy" work environment might be more than willing to facilitate personal audio archives, and my concern is this is completely legal. BUT, as we all know, this doesn't stop interested parties in thwarting such use for their own profit. They could very easily loby congress to make such specific use illegal... And that's my beef.. That just because there is a law, doesn't mean it's the end of the story. There are millions of horrible and immoral laws. I personally feel strongly that such media restrictions fit into this category.
This is pure bullshit, because by your thinking, we could just play the music through one big digital loudspeaker across the entire world and it'd be OK.
There's a BIG difference between a loud "speaker" and broadcast. Broadcasting is coverted sufficiently (e.g. radio transmission, and currently the napster simulcast, bla bla bla). The issue is that of constrained transmission, e.g. a "loud speaker", or an intranet, where a finite number of users are affected. We're talking chump change, and not the buy once, distribute infinitely. With this, it's regional purchasing which has a spot hit-rate similar to the sale of CDs as it stands (maybe with one additional order of magnitude). Unless these individuals then rebroadcast their local copies (e.g. have home broadband connections where they share music pirated from work), then there's no statistical harm, since each micro-cosm must purchase an original copy.
My point was the amount of the fine was not comparable to a suite against a loud-speaker.. Yes a court agreed with you on the amount, but that's circumstantial; doesn't make the judgement right.
I personally am disgusted that loud-speakers are illegal to use on owned media, but I understand that courts currently rule that way.
I can see a company like IBM getting sued for sharing millions of songs amongst it's employees, but a small company (less than 15 people) that I know of used a simple non-published mp3 archive, where people had their own personal folders that they could bring music from home, so they could listen to it at work.
Though not enforced, theoretically, the only use is to allow individual listening to their own music on a storage facility greater than that of their own computer. It was more cost effective to have one big large hard drive then have a dozen large hard drives (not to mention the company was SCSI, so it would have been an administrative nightmare to upgrade all the machines this way).. Not to mention that the individuals worked on several UNIX machines, and could easily mount their drives as necessary in the different labs.
To make this legit, they could have restricted access to each mount, and thus no sharing would occur.. As I said, this wasn't enforced however.
How can a networked computer be allowed to legally space-shift legitamit media without fear of the RIAA / SS?
The real question here is that in a small company, does the RIAA really have jurisdiction. With a company that small, people would ahve lent each other CDs from time to time anyway (often duplicating onto cassette tapes, which has never been really refuted).
Should such a company be worried? Or is the gistapo getting closer to getting it's power stripped?
A company promoting piracy is even worse than the individual person who feels it's OK to shoplift or steal music.
Piracy is when you take music that didn't belong to you (or your immediate family). We're not talking the distribution of music.. We're talking the playing of music threw a digital loud-speaker. It's at most no different than a company playing a CD throw a real loud-speaker, getting caught by the immorally abusive RIAA. I can not believe such an offence is worth $1 million in back-pay (ignoring for a moment, that I believe that such activity is illegal).
If individuals pirate the music off the mp3 server, then they are individually responsible for piracy.
The whole question of napster is still unresolved as far as I'm concerned, so my chief argument is that it's not a cut and dry bad company.
For a 1meter event horizon: we have: v_escape = c = sqrt( 2G*M_body / ( R_body = 1 )) => M_body = 2.99E22 kg (roughly 1/2 size of moon)
gravitational acceleration at surface of body is: F=unit_mass x a = G x M_body x unit_mass / R_body^2 => a = 2E12 m/s^2 which is roughly 1/2c^2.
The greatest energy you could contain would be E=mc^2, but you'd have to have excess mass left over to accelerate. From this, it would be impossible for an intact body to escape the event horizon (e.g. the destructive force of a perfectly efficient matter-energy conversion imparted 100% in one direction onto a body of matter would be devistating)
This is a simple argument based on quickly running through my old physics text book... I'm sure there are other approaches that would demonstrate the impossibilities of escape.. e.g. derived equations.
There is only one wrinkle in this endeavor, as far as I'm concerned.. There is a large body of scientists that disbelieve the singularity of a black-hole. It doesn't make sence. Thus, if an event-horizon producer must have spacial geometry (other than a point), it has to have density. That density will most likely be non-uniform or have maximal density: e.g. the proposed Bose-einstein condensate occupies a set of minimal quantum states which means greater "mass" requires a greater expanse.
If there exists a max density, then eventually the radius of the body would grow until the event horizon dissapears.
If there isn't a max density then there could be undulations (density fluxuations) which warp the event horizon (thereby allowing burps like solar flares). These warps would magically allow matter towards an edge of the event horizon to suddenly be on the outside and thus could escape (given a pre-existing and nearly infinite buildup of energy).
Another interesting point of view: For a solid spherical constant-density object, the center has zero gravity and the surface has the greatest gravity (due to counter-balancing forces). Most likely density will shrink radially outwards as a warped exponential. The inside will be a bose-einstein condensate, then there will be a layer of solid, then liquid, then gasious-plasma all the way out to the event horizon (and most likely beyond). From this, there is an uneven force distribution. The bose-einstein condensate will be at zero gravity (albeit with lots of inward force). For it to achieve this state, all of the kinetic thermal energy needs to be "squeezed" outwards. Due to the different states of matter, there should be a multi-tiered set of corona's. Further, since the gravitation is zero in the center, energy from those coronas should be allowed to probagate outwards. But as we've calculated, the event horizon limits how far that energy can extend radially. Thus, there should be a massive corona somewhere mid black-body. This is because energy CAN go outwards from the center, and it can only go inwards from the edges. Each phase-layer will amass a nearly infinite amount of energy over time, which will allow it to grow outwards by tiny amounts (as the energy accumulates). At equlibrium, this energy corona should be at a relatively constant radius. I'm pulling stuff off the top of my head, so I'm sure there are forces I'm missing. I can't even comprehend the complexity when we consider a growingblack-body at the moment.
The net effect is that of a giant blender. We take matter, and literally rip it to pure randomized energy: running it through most every state of matter, compress it to hell, super-heat it (in the corona), then eventually sweat it back out again.
Personally, I believe the whole point of it [black-bodies] is to destroy information. While theoretically you can't create or destroy entropy, we're talking 99.9999999999% loss of information, and that's got to account for even God's round-off-error. (Speaking metaphorically)
Anyone have refutations, or additions?
Note, this is all based on the idea of a non-singularity (which I personally must believe). Later work is based on the artificial concept of maximumal density (extrapolated from quantum states).
-Michael
p.s. Non-singularities are described by several existing theories. While I only have a crippled lay-person's understanding of string theory, another more controversial theory (which I consider plausible) is that of Ether. Here's a sight that I've researched (aethro-kinematics)
I've used clearcase (great tool for many things, but slow and expensive), cvs (cheap, functional, but frustrating at times), and perforce. For those that don't know, perforce is commercial but not that expensive.
perforce makes use of sequence numbers for just about everything.. It uses RCS as the backend, and berkley hashtables for a database. Unlike CVS, all files are initially read-only, and you have to "edit" a file (register an edit with the server). This along with the database provides very extremely fast revision-control operations (diffs, checkins, updates, submits, etc).
perforce has a really sophisiticated branching system (I found a few nifty advanced uses for it, though I wouldn't recommend getting too creative like I did). There is a free version of perforce that only allows a single user. Doesn't allow multiple branches or anything either... But if you're a business, then I'd definately suggest that it's worth it.. It's all the advantages of RCS/CVS with only the problem of cost. (I think it's $200/head / year).
In general, however, you really should establish a commision process... We typically have multiple branches dedicated to different aspects of development.
Each developer gets his/her own branch.. Then there's an integration branch.. A single human being has access to the integration branch.. It is his/her responsibility to take in the changes (from a posted commit number) from each developer's branch and bring into the integration branch.. That branch should then run through sanity testing (to verify more than freedom from conflicts). Finally when everybody is happy, the integration branch gets merged into the main branch (as a form of release).. At each stage, commit labels shbould be applied (for further backtracking).
but I'm getting the impression that they are targetting the latter.
They've been trying to get away from that mess since they released NT4
Here's the quote:
The development of the new file system technology is so difficult that Microsoft may have to market two distinctly different product lines while it completes the work--a move Ballmer concedes would be a huge step backward in the company's long-sought plan to unify its operating systems with Windows XP and Windows.Net Server
Whatever this ends up being it's a good bet it will be fully backwards compatible.
Not necessarily. The article did say that they needed to split the development lines. This line would focus on the.NET archetecture. I'm not sure if this means that they'll have to make 2 offices, or maintain two completely separately OS's. I would think only the former is necessary, but I'm getting the impression that they are targetting the latter.
Other's have mentioned this, but I'll say it anyway. 64bit addressing has no limitations except for the physical number of pins comming out of the CPU; and that can be overcome by simply serializing 2 x 32. As for caching (which other's have brought up), obviously a given architecture would have to use segmented regions (say of 4 Gig max cachable, etc). The main advantage of full 64bit addressing would be proprietary motherboard / PCI cards that allow NUMA style memory architecture's etc. It's not that a full 64bits are needed, but that an arbitrary memory segmentation might be desired where the high bits divide the different nodes, etc.
Further, 64bit nubmers are -extremely- common for database architectures (primarily as ID's or what-have-you).. Hell, we're seeing a lot of 128bit numbers already, and 32bit architectres have to resort to slow big-num algorithms. This sort of operation requires 64bit INTs as opposed to void*'s but the two typically coincide within a given CPU.
Actually, no, there wouldn't be HUGE transmissions across the http pipe. (That's what FTP is for anyway.)
Try pasting a multi-K error report in bugzilla. I've had co-workers who would paste a dozen K of java-debug messages into a bug. Textarea allows the user to really screw with your system (and you know what; sometimes it's necessary). There's no reason why enctype=multipart/form-data shouldnt be able to handle such volume. Further, FTP ONLY works on files. What about meta-downloads.. Dynamically generated images, files ripped straight from a database, etc. The alternative is to save the data into temp files... But how long should those files live.. If you have a 20 meg file and someone downloading over a modem, you're probably going to incorrectly set the timeout before file-deletion.
The reason for using TCP was that it was the easy -- the lazy -- way out.
Yes, and good for them.. Why reinvent the wheel? I'll give stronger claims below.
Not to mention, on such large transmission, UDP provides no error-recovery.
Again, "so what"? We have that now -- I routinely get stalled TCP connections, broken links, incomplete images... and I just wait a few minutes, and then click on "Reload" to see if it gets better.
And how is it any better with UDP? At least with TCP, you have some semblence of a connection; your browser window can show you how long the OS thinks the connection is good. With UDP, you rely apon arbitrary client-side timers, and depending on your proprietary protocol, you have no checkpoints, so you can't reliably tell the user how far into the process you've gotten. (e.g. with TCP, you know when the client has at least fully read your request). UDP is not scalable, since any fault tolerant features are going to be less efficient at higher levels. Sure UDP is fast for quick-and-dirty requests, but that's not representative of the majority of modern requests.
As for your complaint.. Broken links are irrelevant to our discussion. Stalled TCP would hardly be avoided by a wrapper around UDP (except possibly if the LARGER THAN 32 K TRANSMISSION WINDOWS ARE FULL!) Hopefully you'll understand why that statement was important. I'll revisit this below. As for incomplete images, there's the concept of byte-serving; works _very_ well for PDFs, and I believe it's avaiable for any static files. Thus if your browser loses some data, it is possible for it to pick up where it left off. The fact that you can hit reload to try again (except for certain types of forms) is a testament to the robustness of HTTP. If you were in a persistent session, the server would assume that you're in a different state, and may say your reload attempt is invalid.
Why does CNN need a persistent connection from you? What state is there that needs to be preserved?
In your original reply, you said that you wanted UDP for simple RPC calls and TCP for sessions. I take sessions to mean anything more than a simplistic web-form. CNN, as well as many other sites have varying levels of complexity in their forms, and could thus have a desire for such.NET-style protocols. The equivalent would be to have the hypothetical "done-right" HTTP protocol maintaining a TCP connection from web request to web request (as I believe you are implying). Thus, CNN would have to maintain thousands (millions over time) of TCP connections open.. Hopefully they're not using a 1 thread/connection model. At least with ASP models, while you still keep memory resident data laying around, your threads get to service alternate requests inbetween subsequent sessioned page loads. That was my point.
And now that we have "invented" cookies, what need is there for TCP at all when discussing HTTP? Error detection? Use checksums.
Data robustness for large transmissions, and to provide feedback to the browser when conditions are sub-optimal. Cookies can even be very large (2k each). I'll refute your claim that checksums are sufficient for error-detection below.
In cases of good network connectivity, TCP is needless overhead.
For good networks (e.g. fully bidirectional, such as a switched network, and independent upload/download channels, and obviously error-resistent), the ack-packets only provide latency, since they are out-of-band, not inlined with either side's transmission. The only remaining overhead is the setup/tear-down time. But Keepalive completely avoids this issue. Fully independent HTTP requests should have enough separation between details that the overhead shouldn't be much of a big deal.. (a[pache]b[enchmark] is an artifical example, and I seriously doubt any good design would really have such stress loads due to independent transactions).
In cases of poor connectivity, TCP is frequently- needless-delay.
In poor connectivity, a checksum is going to provide HORRENDOUS delay. It's all or nothing. If you ever have more than one packet (due to ip-framentation) trasnmitted, you'll likely never get a valid transaction. There is no excuse for reimplementing the TCP model in your proposed UDP framework; it would be less efficient due to the loss of low-level accelerators, robust coding, etc. Thus, simple checksums would require retransmission from the begining after each timeout. (Note that timeouts due to dropped packets are the primary source of delay with TCP, to my knowledge, so you don't avoid that problem with UDP+checksum). NFS, if I am correct foregoes TCP for use of simple checksums, but do you know anybody crazy enough to mount NFS over the inet? Above you imply using FTP beyond a certain threshold to avoid the problem, but DHTML is too dynamic for that.. Rather often (anymore) you get very large data-sets.. SOAP/XML are not going to make this any less true.
I had other points to make, but accidently closed my browser window, so I'll leave it at this.
I've long thought that HTTP should have been a UDP protocol for simple stateless request/responses; for state-preserving communication,
If HTTP were UDP then you'd be relying on IP-framentation to get HUGE transmissions across the pipe (e.g. file-uploads, large form-fields, to say nothing of the downloads). Though I'm not too familiar with practical installations, I thought I've read about firewalls disallowing such fragmentation. Not to mention, on such large transmission, UDP provides no error-recovery.
TCP should have been used, and a single connection kept for the entire interaction.
If TCP connections were maintained, then places like cnn.com would go insance with the millions of persistent TCP connections (which often take forever to timeout and die as it is).
Don't know if you've ever taken advanced economic courses, but there are certain natural monopolies in the world. It's possible for firms to attempt to compete in these areas, but what happens is that the costs are so high and the public demand is so low that it is impossible for two companies to break even when the customer base is devided between them.
Imagine, for example, Irridium. Hardly anyone could concieve of a way to break even with the venture. Imagine if two or three other companies attempted compete in that market.. The tiny customer base would be devided, and all the companies would go belly up; billions of investment dollars would go down the tube. (Which already happened for just the one company)
As strange as it seems, it's often possible for governments to subsidize monopolies to keep them alive (utilities, telephone, cable, etc). Often, what happens is that the monopolies are regulated (such as requiring them to charge exactly their marginal cost (cost for each additional unit of production, eg how much the coal costs to produce another kilowatt hour + labor), which sometimes is below their average cost, and thereby requiring government subsidization. The concept of public well being (the economic word is welfare but the word has a different public meaning), is often maximized under such conditions, even though intuitively it seems asinine. Regulated monopolies aren't really that bad, they just have to be hit with all sorts of fines regularly, and they're subject to political bribes, etc. The alternative is lack of social progress (no power, water, garbage collection, etc).
I abhore comcast, and I don't know if they're at the point of receiving government subsides / grants, but imagine the cost of laying thousnds of miles of fiberoptics. That sort of competition is pretty hard to come by. Only thing government can do is either break comcast up regionally (creating smaller local monopolies), or purchase the lines and rent them out to baby-casts similar to what happened to the telephone companies (though I don't know exactly how this was worked for the bells). Thus far, comcast isn't requiring that we all purchase digital converters for our houses exclusively from them (as AT&T effectively did), so I don't see anti-trust leglislation any time soon.
I disagree.. If 99% of all application software is written exclusively for windows, and MS has a monopoly on Windows, then OS manufacturers can not have access to that market..
Thus it is a non-trivial thing to generically label them as a monopoly. Effectively, if you wish to sell a software platform, you can not compete. I can make joe cable-company, but it's impossible to compete with the regional monopolized cable companies. Thus if the cable company illegally exerts it's influence against the company, they're liable. Course, for some things, like cable, it's benificial to have a monopoly. Howver, I have absolutely no believe that such is the case in the software market.
I thought that this was the crueso. They don't exactly offer performance boosts as a selling point.
If you have a target CPU, and a target OS, then you can make highly optimized compilations.. Just look at Quake. They've always optimized their code for the intel line (P2, P3 being best lately). A VM can't make several types of optimizations.. Once you're down to assembly, things like load-order are important (and x86 is horrible at dissassembly-based optimizations; no hints, and few registers).
For consumers, most only purchase on evolutionary leaps in performance; thus 50% increase or more (going from 486-66 -> P100 -> P2-300 -> p4 2,000). Theoretical gains of 5-20% based on timing isn't impressive to this realm. And for server-class software, they're going to demand hard-compiled and optimized code, which a VM could never achieve.
So basically you're saying that computers are magical radio-wave transcievers? Funny, I thought computers were based on capacitively switched [Bi]CMOS transistors. This means the "logical operation" travels at the speed of the capacitor charge / discharge times. After the ramp-up, ramp-down time (further delayed by theinnefficiencies of junctions), then the signal travels at the drift velocity of the electrons trapped within the conduction-band; significantly slower than a stream of free-flowing electrons, much less a single electron going full-tilt.
In fact, when electrons start going close to the speed of light within a silicon, there's typically an avalanching effect (utilized in zenor diodes). Channel break-down can easily occur under such situations (caused by relatively high voltages).
To my understanding, the single biggest speedup in the past several years was the introduction bipolar transistors into the CMOS frame-work. Bipolar are very fast (non-capacitively switched), have high current, high amplification, but are power-hogs and require difficult geometries to manufacture. My understanding of BiCMOS is that FET's are used everywhere, but when a FET needs to be charged quickly (or generally requires high current output), a bipolar device is attached on the output as an amplifier. You get the best of both worlds (with the possible exception of the geometry limitations).
Wiring obviously was an issue because new copper based CPUs can run cooler and faster.
I only have an undergraduate understanding of the processes, but the simple point is that there are paracitics all throughout the architecture, and we're discovering efficincies everyday which provide percentage increases in overall performance. Thus it's not the speed, but the sophistication of the design.
There's lots of work going into light-based computing, but I don't think this will ever win out because they're plagued with even bigger interconnect problems and thus paracitics.
if you look at the transistor counts, NVidia's graphic chips already are more complicated than most CPU parts. This is quite do-able.
There's more to [CG]PU complexity than transistor count. Look at the 512Mbit memory cells that run for only a couple dollars a chip.
The trick is inter-related logic complexity. To my understanding the existing GPUs have no issues with backward compatability (so much of the x86 overhead is avoided), the core itself is pipelined and modular, so the complexity is spread out across the whole chip (independent teams can work on their own components with little concern for sistern components, whereas every ounce of performance is being squeezed out of x86's which require complete coordination). Further, graphics acceleration is simply the application of graphical algorithms into silicon. While I'm not quite sure which algorithms there are, the possibilities are endless. Imagine a fast-fourier transform implemented as a SIMD floating point instruction. You create an array of floating point logic units, and interconnect them. The floating point unit is pretty much a common-off-the-shelf design, so the only real logic you apply is the interconnectivity.
I'm not saying that GPU's are easy to design, I'm just saying that hardware filters are designed this way all the time, and I would'nt be surprised if a large percentage of the nVida chips weren't stock logic modules.
While I don't have an issue with anything you said. I'd just like to say that I've successfully worked on _several_ large scale (million+ lines of code) projects in perl. There was not a single complaint about the usability, readibility. The key was functional / technical documentation. It's a branch of [software] engineering that has somehow been forgotten.
When you actually design a project before writing it, and you break the project into modules, then docment the hell out of the APIs, then it doesn't matter what language you use.
Many companies runs important web applications on Java platforms. I
think you can rely on the latest JVM's.
I still think that java is too new to use for generic enterprise operations. I've worked with Java+MsSQL-server, Java+Oracle, Java+ANY GUI, and I've regularly found production flaws that we've had to work around. I'm sure newer versions of java fix many of the older problems, but the API dramaticaly changes so often that you're CONSTANTLY on the bleeding edge. Since they haven't given enough time for a given API to settle down across multiple platforms (e.g. open-sourced initiatives can't keep up), I doubt that Java will ever achieve robustness. To further the point, a new version of JDBC just came out with boat-loads of new untested features.
Java CAN work, if you pick a robust platform, a robust version and well-aged API components. But it's very tempting to use the latest / greatest, because functionally it solves your problem more efficiently, and thus you're prone to bizzar production-time errors (as I've encountered).
In comparison, the basis of the perl language only changes in the major version levels. And we've been at perl5 for a Very long time. Most of the change is in the CPAN modules, which given enough proving-time probagate down to the standard distribution. The changes to the core are rare (only in perl5.005 did threading / agumented reg-ex's really hit and thus cause some stability issues). Thankfully many of the features were off by default, and some (raw threading) have since been revoked. It's a VERY different mentality, than MS / Sun, who seem to want to sell themselves via feature-bloatware.
Perl has consistently worse performance than Java for typical OO
applications.
I would be very interested in seeing your benchmarking results demonstrating this. Part of the problem is that you're comparing apples to oranges.. You don't solve problems the same way in Perl that you do in Java.. Java is a forced solution (e.g. OO with method-based operations). Perl uses a combination of simple function calls, HEAVY use of low-level C-based functions, and a sprinkling of OO here and there - just to pretty up the API. Granted, OO on Perl 5 can be horrendously slow (especially if you have the inheretence-tree of java; given the linked-list lookup style method dispatching). But Perl's garbage collector alone puts Java to shame. My Apache apps with mod_perl never exceed 30Meg each (with large amounts of large-temporaries), while most of my apps never reach a meg in size. My Java-apps HAVE to start at a God awful size and are both CPU and memory hogs (non ref-counted GCing is horrid for page and cache thrashing). Yes there are memory leaks in ref-counting, but it's well known and designed for in perl5 APIs (or you spank the module writer). The only potential pausing that ref-counting does in perl5 is deallocation of massively nested structures. But then again, perl5 is more determinisitic than java (at least until perl6, but I won't get into that). We're not even going to get into the *cough* jit-startup time.
Ok, if you do very much string processing this might be a valid
point. But this dont apply to most applications. Typically the Java
regexp packages which is part of JDK 1.4 is enough. If 0.01% of your
application is string processing it's not justified to have special
language constructs for it.
Again, apples to oranges. Perl5 uses strings as a fundamental data-type. Integers, floating point, exceptions, error-messages, parameters. Just about everything (short of tcl) is at one point potentially a string. While I don't know how intentional this is, this fact allows a dramatic efficiency when making string-manipulation the number-one priority for the language. While in Java you could apply a sequence of catch (ObjType1) catch (ObjType2), etc, which essentially becomes a switch statement, in perl you are relegated to if ( $@ =~/mem/ ) elsif ( $@ =~/unbounded/ ), etc... Giving you the potential to solve mind bogglingly complex problems with an intuitive nature. Granted it's difficult to optimize away much of this (perl6 should address this issue nicely), the flexibility allows you to find very efficient solutions (both in programming cost and CPU cost). To boot, the number one growing field is text-based web / XML generation.. I'm sorry did you say 0.01%? Care to find a more realistic number there?
Thus, the power of the string can in no way be cast aside (simply because c, c++, java finds 5-10% use for it).
But does it have the power of Swing? And Swing is really fast running
under JDK 1.4 on my Win2k computer.
YES!!! There is more to Perl than Tk. There is Gnome, Qt, MFC.. The only thing I'm not aware of is Swing proper, but who cares, it's not a great design and buggy as hell!! (Maybe as of 1.4 the 1.2 features work properly, but not across all platforms).
Gnome even has a perl generator within Glade.. I find glade MUCH nicer than forte' (at least the version I last looked at).
Agreed, multithreading is a vital part of any modern application.
I disagree. Multi-threading is inherently non portable. Personally I believe MT allows for bad design. The programmer gets lazy and just relegates tasks to other threads (ignoring the scalability and communication overhead). While certain classes of operations are more efficiently handled in MT (especially on MP systems), the majority of algorithms can have the highest in performance with single-threading. MT is great for response time, and it does have a certain elegance, but don't talk to me about elegance when debugging MT code.
That said, there is, of course, primative MT support in perl5, and perl6 will support it natively (though I believe (and desparately hope) that MT won't be required, nor activated by default). I say primitive, not because they're limited in functionality, but instead in efficiency (global locks, etc). I BELIEVE the stability is sound, but the CPAN library support is non-existant (just try and compile an Oracle DBD with use5005threads enabled).
Lastly, I'd like to point out that my disagreement is with the phrase "modern application". A modern _language_ should most certainly provide robust thread-like facilities(even if it's just virtual threading), but most certainly threading does not apply to MANY real-world applications. Take web-services for example. There is a big push for MT web servers.. Apache 2.0 is a good example (of course IIS has always had it). While MT allows rapid concurrent static content retreival, it has several costs with respect to dynamic content. First, it is less stable; one thread might corrupt co-existing app's memory-spaces. Secondly, designs that require MT are not easily segmentable. Apache 1.3 makes little difference whether the dynamic-app is on the same machine or on independent machines. IIS-modeled ASP servers are not directly translatable to multi-machined applications (without significant clustering support). Similarly Java servlets does not [natively] provide for much inter-process communication, except when mapping sessions to workers.
The point here is that even with MT, multi-processing solutions are still sometimes necessary (e.g. using serialized access to a common database is necessary for basic communications, thereby avoiding many of the advantages of MT). To further the point, Apache 2.0 prefers a mixed-mode, where there are several independent processes which can optionally run n-threads each. This gives you the best of both worlds; services that can take advantage of threading (like static paging) can, while the benifits of the age-old IPC-based single-threading persist. This also allows legacy apps like mod_perl to work (in ST mode).
Elegance - This is another area where Perl fails, but another area
where it doesn't matter:-)
I dont agree. Simplicity is very important for code maintability. Java
code is very easy to read for a person that hasn't written it.
A basic turing machine is simple. Care to say any kind words about it? e.g. there's more to the equation when deciding who's "best" for a task.
I agree with you, but with reservation; you can write bad code in any language. But more relevantly, you _can_ choose a coding style which is readible in perl assuming that the reader actually KNOWS perl.. This is the biggest falicy about perl. Most people that berate it don't even know regular expressions (or sh / awk). Once you know them, you understand WHY the syntax is the way it is, and understand its benifits. After using it long enough, most of it is intuitive. I regularly read through CPAN code and always understand everything EXCEPT the algorithms. (which are sometimes obtusely done). I have the exact same problems with Java, though often it's more difficult unless you have the java-doc window open with valid documentation. Inlined hash-based parameters blow the doors off positional parameters in terms of readibility. Sadly, Java provides no such capability; applying hashes actually draws out the code such that it's even more difficult to understand.
Similarly Java is so verbose, that the syntax often gets in the way of understanding. Part of TMTOWTDI is that you write the code in terms of significance:
die "something went wrong" if complex-bad-condition;
Is more intuitive than:
if (complex-condition) throw bizzar-sounding-exception;
While at the same time the Java-style syntax is still an option.
Further, whenever I've had to write parsers, the intent of the VERY LONG code is anything but obviously; to say nothing of the debugging.. A simple regular expression (which is only recently standardized in java.. And oh, by the way, they used perl5.004's syntax) takes less than a line and is completely intuitive once you trace it out. The point is not to bash Java, but to praise the foresight of perl, awk, etc. for their designing languages that very nicely solve problems. Java started with your basic premise (the elegance and predictability of lisp / minimalized base operations), but found that this was not useful in the real world. They had to incrementally evolve, to find their real equilibrium (demonstrating that they missed their initial target). Now they're at v2.0 and have several "bolt-ons" which limit the elegance.. C# basically looked at Java and said, ok, we'll do java freshly (avoiding compatibility issues). Perl is a frankenstein of a language, but not because it missed it's initial mark, but because the world evolved (from c-based procedural, to OO. From quick-and-dirty RAD to quick-and-efficient web-apps. From no-holds-bar speedy core to user-extensible cores). That perl has lasted this long brings to mind the x86 processor (which even today has no death in sight). perl6 is going to be a complete rewrite, and it'll be sad to see the last vestigates of that genome dissapear.
In short, Perl gives you the ability to write "understandbile" code, and peer-pressure / corporate mandate should be enough to enforce this. The only thing left is the enlightenment of the developers. Let the best tool win the contract for my job.
Although I am against the non-commercial restriction of GPL. Hmmm, Perl is GPL, isn't it?
Perl has the Artistic license which essentially says you can choose whether you perl modules / perlX patches are GPL'd or BSD-like (don't remember the details of the more free-varient).
So GPL advocates can promote their anti-pay mentality, and businesses can still make money.
Slashdot Mirror
and then
Wow, and AMD is sure to remember Intel's integration of a RAMBUS controller into it's Pentium 4, and how embarrising that was after Intel decided to rethink their strategy.
Could someone explain to me how choosing a particular technology for your customers and saying this is all you're allowed to use fosters competition?
-Michael
I usually start people off with pico. It's less stressful (especially when you're dealing with non CIS types)
I have yet to be on a UNIX machine that didn't have pico, and unless you do serious editing, you don't need all the power of vi/emacs.
-Michael
The complaint about using grep + awk is just stupid. grep is significantly faster than awk, anyway.
Couldn't find where you were referencing this (guess it was in your link). In any case, I don't see where grep is shown to be "faster" than awk. I'm sure you know their respective purposes, but awk and grep use the same type of searching algorithm (DFA), so the only slowdown in awk is because it does more with each line (e.g. run the provided script). sed on the other hand (like perl) uses NFA (so as to do search/replace on the input stream), which is fundamentally slower.
Just felt like throwing that tidbit in.
-Michael
Other useful commands:
/dev/fd/0 # for when it simple MUST have a command-line argument file-name
... }
cmd <$(program execution) <$(prog2)
# output of multiple executions instead of a single pipe (usually cmd-dependent)
cat file | cmd
cmd "adf${FOO}asdf\"dfdf\"sdfs"\ sdfs\ \,
cmd <<EOS
here is my long text
bla bla bla
EOS
# quoting in general is MUCH better in *sh than what I've seen available on windows (not 100% sure about cmd.exe; please correct me if I'm wrong about it not have a fully encodble string command line)
# side note, bash sucks compared to perl's string processor (e.g. qq(...) )
cmd1 ; ( cmd2 && cmd3 & ) || cmd4
# serialized, parallelized, and conditionally based command execution (not to mention sub-shelled)
nohup cmd
# disconnect from shell and log output (in case modem hangs up, or in more modern situations, the general terminal disconnects)
screen
# while not strickly the shell, the pseudo-terminal technology easily allows detachable / reattachable terminals
All the test commands (not quite sure how well cmd's scripting works)
alias ls
funcion ls() {
ls
\ls
which ls
# multi-teered command-interpretations
ulimit
# control resource consumption (granted this isn't a shell thing, but it's nice to do from the shell)
times
# see my resource utilization (see ulimit for caveat)
jobs
# and other such wonder background management tools (see above caveat)
#There's ANSI color capabilities
cmd $((math-expression))
cmd ${PATH#/home}
#Variable substitution / manipulation ${var[sym]param}
Don't know if cmd.exe has file-descriptor modifications like [n]>&- (close descriptor n)
Then, there's my favorite.. emacs or vi-based low-bandwidth, high-productivity editor commands. A command is considered to be like a mini-program, so the editor treats the unlimited line-size as such.
-Michael
Your argument is sound, and presumably arguable, up to your last step.
I agree that there are probably issues with my approach with the current law, however, compare this to software duplication; Microsoft even. MS acknowledges that for a system administrator it's tedious to man-handle thousands of OS/Office CDs, and thus only a master set is utilized and per-installation serial numbers are used.
Laws have to change with the times, and I refuse to sit still when the status quo is being argued.
At the very least, a form of secondary use licensing should be available, which is the right to use the digital media in other form, potentially originally derived from a CD, the web, etc. This would be adequate to allow an online site like mp3.com to consolidate binary images.
Even still, the argument that multiple digital images "might" allow simultaneous reuse (and thereby actualize duplication) doesn't mean it realistically will (e.g. single people that live alone like myself). That you currently can put an mp3 image on a portable player alone demonstrates the flaws in this logic. (Not that there wasn't all sorts of fear when this concept was first started).
-Michael
Easy, if you know its illegal you shouldn't be doing it. :)
Someone at that company must have had broadband at home. Set up the server there and presto bingo! The likelyhood of it being the company's fault rather than your own just plummeted.
You're missing the point. You _are_ allowed to put your purchased CD in the CD-ROM drive-tray at work last I checked. From that, it's trivial to rip the CD and save the files locally so you don't have to bring your entire CD collection back and forth from home. It is beyond immoral for a company to tell you how to live your life (e.g. that you must carry your original CDs with you as you would an ID card (which so far is only enforced for visa's and drivers licences in special circumstances)).
Assuming that you agree with me thus far, then it is not too far of a stretch to fathom a personal archive of music at work on a work machine (much like you'd install your own background image, or heaven forbid, your own OS).
While company policy might restrict such use of a computer (e.g. a bank that disallows entry/departure of data/files), most aren't this strict.
A company that encourages a "happy" work environment might be more than willing to facilitate personal audio archives, and my concern is this is completely legal. BUT, as we all know, this doesn't stop interested parties in thwarting such use for their own profit. They could very easily loby congress to make such specific use illegal... And that's my beef.. That just because there is a law, doesn't mean it's the end of the story. There are millions of horrible and immoral laws. I personally feel strongly that such media restrictions fit into this category.
-Michael
This is pure bullshit, because by your thinking, we could just play the music through one big digital loudspeaker across the entire world and it'd be OK.
There's a BIG difference between a loud "speaker" and broadcast. Broadcasting is coverted sufficiently (e.g. radio transmission, and currently the napster simulcast, bla bla bla). The issue is that of constrained transmission, e.g. a "loud speaker", or an intranet, where a finite number of users are affected. We're talking chump change, and not the buy once, distribute infinitely. With this, it's regional purchasing which has a spot hit-rate similar to the sale of CDs as it stands (maybe with one additional order of magnitude). Unless these individuals then rebroadcast their local copies (e.g. have home broadband connections where they share music pirated from work), then there's no statistical harm, since each micro-cosm must purchase an original copy.
-Michael
My point was the amount of the fine was not comparable to a suite against a loud-speaker.. Yes a court agreed with you on the amount, but that's circumstantial; doesn't make the judgement right.
I personally am disgusted that loud-speakers are illegal to use on owned media, but I understand that courts currently rule that way.
I can see a company like IBM getting sued for sharing millions of songs amongst it's employees, but a small company (less than 15 people) that I know of used a simple non-published mp3 archive, where people had their own personal folders that they could bring music from home, so they could listen to it at work.
Though not enforced, theoretically, the only use is to allow individual listening to their own music on a storage facility greater than that of their own computer. It was more cost effective to have one big large hard drive then have a dozen large hard drives (not to mention the company was SCSI, so it would have been an administrative nightmare to upgrade all the machines this way).. Not to mention that the individuals worked on several UNIX machines, and could easily mount their drives as necessary in the different labs.
To make this legit, they could have restricted access to each mount, and thus no sharing would occur.. As I said, this wasn't enforced however.
How can a networked computer be allowed to legally space-shift legitamit media without fear of the RIAA / SS?
The real question here is that in a small company, does the RIAA really have jurisdiction. With a company that small, people would ahve lent each other CDs from time to time anyway (often duplicating onto cassette tapes, which has never been really refuted).
Should such a company be worried? Or is the gistapo getting closer to getting it's power stripped?
-Michael
A company promoting piracy is even worse than the individual person who feels it's OK to shoplift or steal music.
Piracy is when you take music that didn't belong to you (or your immediate family). We're not talking the distribution of music.. We're talking the playing of music threw a digital loud-speaker. It's at most no different than a company playing a CD throw a real loud-speaker, getting caught by the immorally abusive RIAA. I can not believe such an offence is worth $1 million in back-pay (ignoring for a moment, that I believe that such activity is illegal).
If individuals pirate the music off the mp3 server, then they are individually responsible for piracy.
The whole question of napster is still unresolved as far as I'm concerned, so my chief argument is that it's not a cut and dry bad company.
-Michael
For a 1meter event horizon: we have:
v_escape = c = sqrt( 2G*M_body / ( R_body = 1 ))
=>
M_body = 2.99E22 kg (roughly 1/2 size of moon)
gravitational acceleration at surface of body is:
F=unit_mass x a = G x M_body x unit_mass / R_body^2
=>
a = 2E12 m/s^2 which is roughly 1/2c^2.
The greatest energy you could contain would be E=mc^2, but you'd have to have excess mass left over to accelerate. From this, it would be impossible for an intact body to escape the event horizon (e.g. the destructive force of a perfectly efficient matter-energy conversion imparted 100% in one direction onto a body of matter would be devistating)
This is a simple argument based on quickly running through my old physics text book... I'm sure there are other approaches that would demonstrate the impossibilities of escape.. e.g. derived equations.
There is only one wrinkle in this endeavor, as far as I'm concerned.. There is a large body of scientists that disbelieve the singularity of a black-hole. It doesn't make sence. Thus, if an event-horizon producer must have spacial geometry (other than a point), it has to have density. That density will most likely be non-uniform or have maximal density: e.g. the proposed Bose-einstein condensate occupies a set of minimal quantum states which means greater "mass" requires a greater expanse.
If there exists a max density, then eventually the radius of the body would grow until the event horizon dissapears.
If there isn't a max density then there could be undulations (density fluxuations) which warp the event horizon (thereby allowing burps like solar flares). These warps would magically allow matter towards an edge of the event horizon to suddenly be on the outside and thus could escape (given a pre-existing and nearly infinite buildup of energy).
Another interesting point of view: For a solid spherical constant-density object, the center has zero gravity and the surface has the greatest gravity (due to counter-balancing forces). Most likely density will shrink radially outwards as a warped exponential. The inside will be a bose-einstein condensate, then there will be a layer of solid, then liquid, then gasious-plasma all the way out to the event horizon (and most likely beyond). From this, there is an uneven force distribution. The bose-einstein condensate will be at zero gravity (albeit with lots of inward force). For it to achieve this state, all of the kinetic thermal energy needs to be "squeezed" outwards. Due to the different states of matter, there should be a multi-tiered set of corona's. Further, since the gravitation is zero in the center, energy from those coronas should be allowed to probagate outwards. But as we've calculated, the event horizon limits how far that energy can extend radially. Thus, there should be a massive corona somewhere mid black-body. This is because energy CAN go outwards from the center, and it can only go inwards from the edges. Each phase-layer will amass a nearly infinite amount of energy over time, which will allow it to grow outwards by tiny amounts (as the energy accumulates). At equlibrium, this energy corona should be at a relatively constant radius. I'm pulling stuff off the top of my head, so I'm sure there are forces I'm missing. I can't even comprehend the complexity when we consider a growingblack-body at the moment.
The net effect is that of a giant blender. We take matter, and literally rip it to pure randomized energy: running it through most every state of matter, compress it to hell, super-heat it (in the corona), then eventually sweat it back out again.
Personally, I believe the whole point of it [black-bodies] is to destroy information. While theoretically you can't create or destroy entropy, we're talking 99.9999999999% loss of information, and that's got to account for even God's round-off-error. (Speaking metaphorically)
Anyone have refutations, or additions?
Note, this is all based on the idea of a non-singularity (which I personally must believe). Later work is based on the artificial concept of maximumal density (extrapolated from quantum states).
-Michael
p.s. Non-singularities are described by several existing theories. While I only have a crippled lay-person's understanding of string theory, another more controversial theory (which I consider plausible) is that of Ether. Here's a sight that I've researched (aethro-kinematics)
I've used clearcase (great tool for many things, but slow and expensive), cvs (cheap, functional, but frustrating at times), and perforce. For those that don't know, perforce is commercial but not that expensive.
perforce makes use of sequence numbers for just about everything.. It uses RCS as the backend, and berkley hashtables for a database. Unlike CVS, all files are initially read-only, and you have to "edit" a file (register an edit with the server). This along with the database provides very extremely fast revision-control operations (diffs, checkins, updates, submits, etc).
perforce has a really sophisiticated branching system (I found a few nifty advanced uses for it, though I wouldn't recommend getting too creative like I did). There is a free version of perforce that only allows a single user. Doesn't allow multiple branches or anything either... But if you're a business, then I'd definately suggest that it's worth it.. It's all the advantages of RCS/CVS with only the problem of cost. (I think it's $200/head / year).
In general, however, you really should establish a commision process... We typically have multiple branches dedicated to different aspects of development.
Each developer gets his/her own branch.. Then there's an integration branch.. A single human being has access to the integration branch.. It is his/her responsibility to take in the changes (from a posted commit number) from each developer's branch and bring into the integration branch.. That branch should then run through sanity testing (to verify more than freedom from conflicts). Finally when everybody is happy, the integration branch gets merged into the main branch (as a form of release).. At each stage, commit labels shbould be applied (for further backtracking).
-Michael
Here's the quote:
The development of the new file system technology is so difficult that Microsoft may have to market two distinctly different product lines while it completes the work--a move Ballmer concedes would be a huge step backward in the company's long-sought plan to unify its operating systems with Windows XP and Windows
Not necessarily. The article did say that they needed to split the development lines. This line would focus on the
-Michael
Other's have mentioned this, but I'll say it anyway. 64bit addressing has no limitations except for the physical number of pins comming out of the CPU; and that can be overcome by simply serializing 2 x 32. As for caching (which other's have brought up), obviously a given architecture would have to use segmented regions (say of 4 Gig max cachable, etc). The main advantage of full 64bit addressing would be proprietary motherboard / PCI cards that allow NUMA style memory architecture's etc. It's not that a full 64bits are needed, but that an arbitrary memory segmentation might be desired where the high bits divide the different nodes, etc.
Further, 64bit nubmers are -extremely- common for database architectures (primarily as ID's or what-have-you).. Hell, we're seeing a lot of 128bit numbers already, and 32bit architectres have to resort to slow big-num algorithms. This sort of operation requires 64bit INTs as opposed to void*'s but the two typically coincide within a given CPU.
-Michael
Try pasting a multi-K error report in bugzilla. I've had co-workers who would paste a dozen K of java-debug messages into a bug. Textarea allows the user to really screw with your system (and you know what; sometimes it's necessary). There's no reason why enctype=multipart/form-data shouldnt be able to handle such volume. Further, FTP ONLY works on files. What about meta-downloads.. Dynamically generated images, files ripped straight from a database, etc. The alternative is to save the data into temp files... But how long should those files live.. If you have a 20 meg file and someone downloading over a modem, you're probably going to incorrectly set the timeout before file-deletion.
Yes, and good for them.. Why reinvent the wheel? I'll give stronger claims below.
And how is it any better with UDP? At least with TCP, you have some semblence of a connection; your browser window can show you how long the OS thinks the connection is good. With UDP, you rely apon arbitrary client-side timers, and depending on your proprietary protocol, you have no checkpoints, so you can't reliably tell the user how far into the process you've gotten. (e.g. with TCP, you know when the client has at least fully read your request). UDP is not scalable, since any fault tolerant features are going to be less efficient at higher levels. Sure UDP is fast for quick-and-dirty requests, but that's not representative of the majority of modern requests.
As for your complaint.. Broken links are irrelevant to our discussion. Stalled TCP would hardly be avoided by a wrapper around UDP (except possibly if the LARGER THAN 32 K TRANSMISSION WINDOWS ARE FULL!) Hopefully you'll understand why that statement was important. I'll revisit this below. As for incomplete images, there's the concept of byte-serving; works _very_ well for PDFs, and I believe it's avaiable for any static files. Thus if your browser loses some data, it is possible for it to pick up where it left off. The fact that you can hit reload to try again (except for certain types of forms) is a testament to the robustness of HTTP. If you were in a persistent session, the server would assume that you're in a different state, and may say your reload attempt is invalid.
In your original reply, you said that you wanted UDP for simple RPC calls and TCP for sessions. I take sessions to mean anything more than a simplistic web-form. CNN, as well as many other sites have varying levels of complexity in their forms, and could thus have a desire for such
Data robustness for large transmissions, and to provide feedback to the browser when conditions are sub-optimal. Cookies can even be very large (2k each). I'll refute your claim that checksums are sufficient for error-detection below.
For good networks (e.g. fully bidirectional, such as a switched network, and independent upload/download channels, and obviously error-resistent), the ack-packets only provide latency, since they are out-of-band, not inlined with either side's transmission. The only remaining overhead is the setup/tear-down time. But Keepalive completely avoids this issue. Fully independent HTTP requests should have enough separation between details that the overhead shouldn't be much of a big deal.. (a[pache]b[enchmark] is an artifical example, and I seriously doubt any good design would really have such stress loads due to independent transactions).
In poor connectivity, a checksum is going to provide HORRENDOUS delay. It's all or nothing. If you ever have more than one packet (due to ip-framentation) trasnmitted, you'll likely never get a valid transaction. There is no excuse for reimplementing the TCP model in your proposed UDP framework; it would be less efficient due to the loss of low-level accelerators, robust coding, etc. Thus, simple checksums would require retransmission from the begining after each timeout. (Note that timeouts due to dropped packets are the primary source of delay with TCP, to my knowledge, so you don't avoid that problem with UDP+checksum). NFS, if I am correct foregoes TCP for use of simple checksums, but do you know anybody crazy enough to mount NFS over the inet? Above you imply using FTP beyond a certain threshold to avoid the problem, but DHTML is too dynamic for that.. Rather often (anymore) you get very large data-sets.. SOAP/XML are not going to make this any less true.
I had other points to make, but accidently closed my browser window, so I'll leave it at this.
-Michael
If HTTP were UDP then you'd be relying on IP-framentation to get HUGE transmissions across the pipe (e.g. file-uploads, large form-fields, to say nothing of the downloads). Though I'm not too familiar with practical installations, I thought I've read about firewalls disallowing such fragmentation. Not to mention, on such large transmission, UDP provides no error-recovery.
If TCP connections were maintained, then places like cnn.com would go insance with the millions of persistent TCP connections (which often take forever to timeout and die as it is).
Don't know if you've ever taken advanced economic courses, but there are certain natural monopolies in the world. It's possible for firms to attempt to compete in these areas, but what happens is that the costs are so high and the public demand is so low that it is impossible for two companies to break even when the customer base is devided between them.
Imagine, for example, Irridium. Hardly anyone could concieve of a way to break even with the venture. Imagine if two or three other companies attempted compete in that market.. The tiny customer base would be devided, and all the companies would go belly up; billions of investment dollars would go down the tube. (Which already happened for just the one company)
As strange as it seems, it's often possible for governments to subsidize monopolies to keep them alive (utilities, telephone, cable, etc). Often, what happens is that the monopolies are regulated (such as requiring them to charge exactly their marginal cost (cost for each additional unit of production, eg how much the coal costs to produce another kilowatt hour + labor), which sometimes is below their average cost, and thereby requiring government subsidization. The concept of public well being (the economic word is welfare but the word has a different public meaning), is often maximized under such conditions, even though intuitively it seems asinine. Regulated monopolies aren't really that bad, they just have to be hit with all sorts of fines regularly, and they're subject to political bribes, etc. The alternative is lack of social progress (no power, water, garbage collection, etc).
I abhore comcast, and I don't know if they're at the point of receiving government subsides / grants, but imagine the cost of laying thousnds of miles of fiberoptics. That sort of competition is pretty hard to come by. Only thing government can do is either break comcast up regionally (creating smaller local monopolies), or purchase the lines and rent them out to baby-casts similar to what happened to the telephone companies (though I don't know exactly how this was worked for the bells). Thus far, comcast isn't requiring that we all purchase digital converters for our houses exclusively from them (as AT&T effectively did), so I don't see anti-trust leglislation any time soon.
-Michael
I disagree.. If 99% of all application software is written exclusively for windows, and MS has a monopoly on Windows, then OS manufacturers can not have access to that market..
Thus it is a non-trivial thing to generically label them as a monopoly. Effectively, if you wish to sell a software platform, you can not compete. I can make joe cable-company, but it's impossible to compete with the regional monopolized cable companies. Thus if the cable company illegally exerts it's influence against the company, they're liable. Course, for some things, like cable, it's benificial to have a monopoly. Howver, I have absolutely no believe that such is the case in the software market.
-Michael
I thought that this was the crueso. They don't exactly offer performance boosts as a selling point.
If you have a target CPU, and a target OS, then you can make highly optimized compilations.. Just look at Quake. They've always optimized their code for the intel line (P2, P3 being best lately). A VM can't make several types of optimizations.. Once you're down to assembly, things like load-order are important (and x86 is horrible at dissassembly-based optimizations; no hints, and few registers).
For consumers, most only purchase on evolutionary leaps in performance; thus 50% increase or more (going from 486-66 -> P100 -> P2-300 -> p4 2,000). Theoretical gains of 5-20% based on timing isn't impressive to this realm. And for server-class software, they're going to demand hard-compiled and optimized code, which a VM could never achieve.
-Michael
So basically you're saying that computers are magical radio-wave transcievers? Funny, I thought computers were based on capacitively switched [Bi]CMOS transistors. This means the "logical operation" travels at the speed of the capacitor charge / discharge times. After the ramp-up, ramp-down time (further delayed by theinnefficiencies of junctions), then the signal travels at the drift velocity of the electrons trapped within the conduction-band; significantly slower than a stream of free-flowing electrons, much less a single electron going full-tilt.
In fact, when electrons start going close to the speed of light within a silicon, there's typically an avalanching effect (utilized in zenor diodes). Channel break-down can easily occur under such situations (caused by relatively high voltages).
To my understanding, the single biggest speedup in the past several years was the introduction bipolar transistors into the CMOS frame-work. Bipolar are very fast (non-capacitively switched), have high current, high amplification, but are power-hogs and require difficult geometries to manufacture. My understanding of BiCMOS is that FET's are used everywhere, but when a FET needs to be charged quickly (or generally requires high current output), a bipolar device is attached on the output as an amplifier. You get the best of both worlds (with the possible exception of the geometry limitations).
Wiring obviously was an issue because new copper based CPUs can run cooler and faster.
I only have an undergraduate understanding of the processes, but the simple point is that there are paracitics all throughout the architecture, and we're discovering efficincies everyday which provide percentage increases in overall performance. Thus it's not the speed, but the sophistication of the design.
There's lots of work going into light-based computing, but I don't think this will ever win out because they're plagued with even bigger interconnect problems and thus paracitics.
-Michael
if you look at the transistor counts, NVidia's graphic chips already are more complicated than most CPU parts. This is quite do-able.
There's more to [CG]PU complexity than transistor count. Look at the 512Mbit memory cells that run for only a couple dollars a chip.
The trick is inter-related logic complexity. To my understanding the existing GPUs have no issues with backward compatability (so much of the x86 overhead is avoided), the core itself is pipelined and modular, so the complexity is spread out across the whole chip (independent teams can work on their own components with little concern for sistern components, whereas every ounce of performance is being squeezed out of x86's which require complete coordination). Further, graphics acceleration is simply the application of graphical algorithms into silicon. While I'm not quite sure which algorithms there are, the possibilities are endless. Imagine a fast-fourier transform implemented as a SIMD floating point instruction. You create an array of floating point logic units, and interconnect them. The floating point unit is pretty much a common-off-the-shelf design, so the only real logic you apply is the interconnectivity.
I'm not saying that GPU's are easy to design, I'm just saying that hardware filters are designed this way all the time, and I would'nt be surprised if a large percentage of the nVida chips weren't stock logic modules.
-Michael
While I don't have an issue with anything you said. I'd just like to say that I've successfully worked on _several_ large scale (million+ lines of code) projects in perl. There was not a single complaint about the usability, readibility. The key was functional / technical documentation. It's a branch of [software] engineering that has somehow been forgotten.
When you actually design a project before writing it, and you break the project into modules, then docment the hell out of the APIs, then it doesn't matter what language you use.
-Michael
I still think that java is too new to use for generic enterprise operations. I've worked with Java+MsSQL-server, Java+Oracle, Java+ANY GUI, and I've regularly found production flaws that we've had to work around. I'm sure newer versions of java fix many of the older problems, but the API dramaticaly changes so often that you're CONSTANTLY on the bleeding edge. Since they haven't given enough time for a given API to settle down across multiple platforms (e.g. open-sourced initiatives can't keep up), I doubt that Java will ever achieve robustness. To further the point, a new version of JDBC just came out with boat-loads of new untested features.
Java CAN work, if you pick a robust platform, a robust version and well-aged API components. But it's very tempting to use the latest / greatest, because functionally it solves your problem more efficiently, and thus you're prone to bizzar production-time errors (as I've encountered).
In comparison, the basis of the perl language only changes in the major version levels. And we've been at perl5 for a Very long time. Most of the change is in the CPAN modules, which given enough proving-time probagate down to the standard distribution. The changes to the core are rare (only in perl5.005 did threading / agumented reg-ex's really hit and thus cause some stability issues). Thankfully many of the features were off by default, and some (raw threading) have since been revoked. It's a VERY different mentality, than MS / Sun, who seem to want to sell themselves via feature-bloatware.
I would be very interested in seeing your benchmarking results demonstrating this. Part of the problem is that you're comparing apples to oranges.. You don't solve problems the same way in Perl that you do in Java.. Java is a forced solution (e.g. OO with method-based operations). Perl uses a combination of simple function calls, HEAVY use of low-level C-based functions, and a sprinkling of OO here and there - just to pretty up the API. Granted, OO on Perl 5 can be horrendously slow (especially if you have the inheretence-tree of java; given the linked-list lookup style method dispatching). But Perl's garbage collector alone puts Java to shame. My Apache apps with mod_perl never exceed 30Meg each (with large amounts of large-temporaries), while most of my apps never reach a meg in size. My Java-apps HAVE to start at a God awful size and are both CPU and memory hogs (non ref-counted GCing is horrid for page and cache thrashing). Yes there are memory leaks in ref-counting, but it's well known and designed for in perl5 APIs (or you spank the module writer). The only potential pausing that ref-counting does in perl5 is deallocation of massively nested structures. But then again, perl5 is more determinisitic than java (at least until perl6, but I won't get into that). We're not even going to get into the *cough* jit-startup time.
Again, apples to oranges. Perl5 uses strings as a fundamental data-type. Integers, floating point, exceptions, error-messages, parameters. Just about everything (short of tcl) is at one point potentially a string. While I don't know how intentional this is, this fact allows a dramatic efficiency when making string-manipulation the number-one priority for the language. While in Java you could apply a sequence of catch (ObjType1) catch (ObjType2), etc, which essentially becomes a switch statement, in perl you are relegated to if ( $@ =~
Thus, the power of the string can in no way be cast aside (simply because c, c++, java finds 5-10% use for it).
YES!!! There is more to Perl than Tk. There is Gnome, Qt, MFC.. The only thing I'm not aware of is Swing proper, but who cares, it's not a great design and buggy as hell!! (Maybe as of 1.4 the 1.2 features work properly, but not across all platforms).
Gnome even has a perl generator within Glade.. I find glade MUCH nicer than forte' (at least the version I last looked at).
I disagree. Multi-threading is inherently non portable. Personally I believe MT allows for bad design. The programmer gets lazy and just relegates tasks to other threads (ignoring the scalability and communication overhead). While certain classes of operations are more efficiently handled in MT (especially on MP systems), the majority of algorithms can have the highest in performance with single-threading. MT is great for response time, and it does have a certain elegance, but don't talk to me about elegance when debugging MT code.
That said, there is, of course, primative MT support in perl5, and perl6 will support it natively (though I believe (and desparately hope) that MT won't be required, nor activated by default). I say primitive, not because they're limited in functionality, but instead in efficiency (global locks, etc). I BELIEVE the stability is sound, but the CPAN library support is non-existant (just try and compile an Oracle DBD with use5005threads enabled).
Lastly, I'd like to point out that my disagreement is with the phrase "modern application". A modern _language_ should most certainly provide robust thread-like facilities(even if it's just virtual threading), but most certainly threading does not apply to MANY real-world applications. Take web-services for example. There is a big push for MT web servers.. Apache 2.0 is a good example (of course IIS has always had it). While MT allows rapid concurrent static content retreival, it has several costs with respect to dynamic content. First, it is less stable; one thread might corrupt co-existing app's memory-spaces. Secondly, designs that require MT are not easily segmentable. Apache 1.3 makes little difference whether the dynamic-app is on the same machine or on independent machines. IIS-modeled ASP servers are not directly translatable to multi-machined applications (without significant clustering support). Similarly Java servlets does not [natively] provide for much inter-process communication, except when mapping sessions to workers.
The point here is that even with MT, multi-processing solutions are still sometimes necessary (e.g. using serialized access to a common database is necessary for basic communications, thereby avoiding many of the advantages of MT). To further the point, Apache 2.0 prefers a mixed-mode, where there are several independent processes which can optionally run n-threads each. This gives you the best of both worlds; services that can take advantage of threading (like static paging) can, while the benifits of the age-old IPC-based single-threading persist. This also allows legacy apps like mod_perl to work (in ST mode).
A basic turing machine is simple. Care to say any kind words about it? e.g. there's more to the equation when deciding who's "best" for a task.
I agree with you, but with reservation; you can write bad code in any language. But more relevantly, you _can_ choose a coding style which is readible in perl assuming that the reader actually KNOWS perl.. This is the biggest falicy about perl. Most people that berate it don't even know regular expressions (or sh / awk). Once you know them, you understand WHY the syntax is the way it is, and understand its benifits. After using it long enough, most of it is intuitive. I regularly read through CPAN code and always understand everything EXCEPT the algorithms. (which are sometimes obtusely done). I have the exact same problems with Java, though often it's more difficult unless you have the java-doc window open with valid documentation. Inlined hash-based parameters blow the doors off positional parameters in terms of readibility. Sadly, Java provides no such capability; applying hashes actually draws out the code such that it's even more difficult to understand.
Similarly Java is so verbose, that the syntax often gets in the way of understanding. Part of TMTOWTDI is that you write the code in terms of significance:
die "something went wrong" if complex-bad-condition;
Is more intuitive than:
if (complex-condition) throw bizzar-sounding-exception;
While at the same time the Java-style syntax is still an option.
Further, whenever I've had to write parsers, the intent of the VERY LONG code is anything but obviously; to say nothing of the debugging.. A simple regular expression (which is only recently standardized in java.. And oh, by the way, they used perl5.004's syntax) takes less than a line and is completely intuitive once you trace it out. The point is not to bash Java, but to praise the foresight of perl, awk, etc. for their designing languages that very nicely solve problems. Java started with your basic premise (the elegance and predictability of lisp / minimalized base operations), but found that this was not useful in the real world. They had to incrementally evolve, to find their real equilibrium (demonstrating that they missed their initial target). Now they're at v2.0 and have several "bolt-ons" which limit the elegance.. C# basically looked at Java and said, ok, we'll do java freshly (avoiding compatibility issues). Perl is a frankenstein of a language, but not because it missed it's initial mark, but because the world evolved (from c-based procedural, to OO. From quick-and-dirty RAD to quick-and-efficient web-apps. From no-holds-bar speedy core to user-extensible cores). That perl has lasted this long brings to mind the x86 processor (which even today has no death in sight). perl6 is going to be a complete rewrite, and it'll be sad to see the last vestigates of that genome dissapear.
In short, Perl gives you the ability to write "understandbile" code, and peer-pressure / corporate mandate should be enough to enforce this. The only thing left is the enlightenment of the developers. Let the best tool win the contract for my job.
-Michael
Although I am against the non-commercial restriction of GPL. Hmmm, Perl is GPL, isn't it?
Perl has the Artistic license which essentially says you can choose whether you perl modules / perlX patches are GPL'd or BSD-like (don't remember the details of the more free-varient).
So GPL advocates can promote their anti-pay mentality, and businesses can still make money.
-Michael