Shouldn't a programmer that wanted to be most efficient start with the highest level of abstractions and work his/her way down as needed?
Abstraction brings effeciency (not in raw cycles but in programming time), portability, and other freedoms. In java, the hardware itself is abstracted so that buffer overflows and other security concerns aren't a problem. C programmers blame buffer overflows on poor programming. I have to ask myself who these people are. If they are so good, then they must have some popular program, right? A program like Bind or Sendmail, perhaps? Even the linux kernel has had buffer overflows.
Abstraction doesn't cost much by the way of performance. Java's abstraction is down from it's initial 1600% to 200% the speed of C. During that time C has went from it's 200% of assembler to closer to 100%. It's reasonable to foresee in the future that any abstraction, even those so severe as the JVM, will eventually aproach native speeds through optimized compilers/JIT/AOT.
The best thing about abstractions in the open source world is that a group of people who use these everyday will be the one's developing them. They will address the issues that matter to developers, and they will only need be addressed once. You don't have to reinvent the wheel when you design your car. If someone makes a better wheel, it's very likely that you will benefit from it if you use an abstraction.
Imagine the nightmare of converting to IPv6 if most people didn't use (at least portions of) the BSD TCP/IP stack??? Compare that to the trivial gains you get by not using it! What if all programers decided to use raw sockets to remove the leaky abstraction?
Fix the abstraction, don't abandon it. Have blocking TCP/IP sends (along side the others) for people that need to know if packets made it. You could just add a function to ask the system if the TCP packet had been sent yet (where sent really meant that an ack was recieved). You get to keep the interface. By the time the interface isn't leaky, you will have a large interface that performs all the tasks of the original, just in a more human comprehensible way.
Another advantage to abstractions is that they can be faster in the end. OpenGL is an abstraction. It's so popular that video card designers will work hard to make that abstraction as thin as possible. Now we have cards that support directly some or all of the functions. It's cross-platform as well because of it is an abstraction.
Don't abandon abstractions because they are slow or aren't all encompassing. Fix the leak, don't toss out the toilet.
You seem to define fad in an odd way. You suggest that anything that comes then goes is a fad. To the average person, I would asume that fad meant that it came and went without any effect. You are assuming that in Stage 3 that the original item didn't effect the building of the next best thing. Object-Oriented programming is based on procedural programming. Eventually, it could become that procedural programming is abandoned, but will not have been a fad because it's "replacement" is a derivative of the original.
I think XP is great because it was the first system designed to teach how to program responsibly. I'm sure it will be replaced by something better, because AFAIK, no one has pioneered perfection in a new field in their first shot. You can bet the farm that the next "fad" will be based on XP. I think you are afraid to change the programming methodologies you already have; therefore, from your point of view, no programming methodology will be more than a fad, because it's not yours and you will never adopt it.
BTW, I've never heard of anyone saying that peicemeal approaches to XP won't work. I've heard the exact oposite. Some people implemnt pair programming, some have great programmers they can depend on (the reasons for pair programming are so that one can catch the others errors, one may leave and someone will need to take over for him). A lot of people implement the test units because no coder is perfect and the synergy of a large system of object (be they libraries or classes) can cause one small change to break a lot of the system. In a large system, you can't remember every little thing you should test and it would be very time consuming to test them by hand.
All things die to give way for the next generation. That doesn't make yesterday's champions fads, but rather old heros.
did anyone else think the song sounded a LOT like bond theme music?
Re:Only if it's the same size disk
on
Ghost for Unix
·
· Score: 2
That only works with ext2/3 filesystems. Most ppl don't use those anymore. You can however resive the fs before you do such evil to it and it work, but it's still not useful in a hetrogenious network.
If the disks are different sizes, you should partition them by hand (or set a script that uses %s).
There are multicast netpipes out there:) You can use |gzip -c| to compress data, and you can use xfsdump/restore to work with active systems.
I want to write my custom solution because then the client can just ask the server for which files are available and which groups are available and I can maximize the network utilization (just have a computer join a group and catch it up to the others while the others are throttled only if the network has been saturated.) Lilo can be configured in the script, but I prefer a block transfer of one single ext2 boot partition to the beginning of the drive and have the mbr boot that partition (set it active and use the default mbr). No problems there either. There's a lot of neat stuff I could do if I wrote my own solution, and I really just want to play with things. I've already learned a LOT about multicasting doing this (like windows machines don't support the spec properly... suprised? no, I didn't think so).
In the end I may end up with a boot floppy version, but size isn't important to me. That's why I'm playing around with it in Java:) I know it's goofy, but it's more just me playing to learn than an actual need. I want to play with gcj too, so we'll see how that turns out:) I know, I could have done it in C and put it on a floppy, but it's just more fun trying to make something wierd like that work:) Besides, it's for a school lab, there is a lot the teachers/students could learn about Java, multicasting, linux, xfs, gcj, etc. If I did C, that would be one less thing for them to learn since they already know C/C++. Few professors and students know much about java. Besides, I have a point to make about Java being good for embedded systems. I started with Lejos (java for lego bricks that I talked them into using for AI). I may try to use J2ME and put it on that open source RTOS kernel Jaluna (it has J2ME support). If J2ME and Jaluna support multicasting (Jaluna and J2ME is supposed to be able to take libraries you need and add them to the installation.) If you are counting here, now they have to learn RTOS kernels, embedded systems, and J2ME. It's a school, they'll get more than they bargained for and the end solution will be user friendly and well documented. Maybe they'll learn some UI design and good documentation habits.
Re:Only if it's the same size disk
on
Ghost for Unix
·
· Score: 2
oh, I wasn't knocking bart:) It's great for what it does. It just wasn't made for what I need to do:) I considered patching bart to do it, but decided to just use nfsroot so I wouldn't have to make an endless supply of CD's:)
If you are looking for a single machine or small numbers of machines to do backup and restore, bart and g4u are great! I used g4u when my lab was homogenous, and it was perfect. I still need multicasting and tar or xfsdump support that is user friendly. It's best I write my own:) Then I can use it as example real world multicasting code for classes as well.
Only if it's the same size disk
on
Ghost for Unix
·
· Score: 5, Insightful
If the target is 1 sector less, you aren't going to be able to use this tool. I still think tar and netpipes is the only way. (unless you use XFS, in such case the best way would be xfsdump, tar, and xfsrestore) I'm trying to write a multicast fileserver for just this purpose. I have a lab of hetrogeneous machines(I take what I can get from the university) that need to be clones(btw, don't forget to run lilo if you use tar/xfs, and don't forget to change the site-key for ssh). I'm ending up using a homebrew solution. There are other good ghost utilities out there that boot from a cdrom(BART perhaps isn't bad), but I still need my own custom solution because I'm not gonna be here forever to make this lab work, and it needs to be "put this in the floppy drive and select options from the menu" easy.
I don't know what you are talking about. How could one starve another in a RTOS? Hard deadlines are set. Most of the time, the process with the closest deadline is selected (some have time estimates and do other optimizations). If a task doesn't complete by it's deadline, it can get preempted because completing the task was just not possible. In effect, you overloaded the system therefore it is unresponsive. AFAIK, any system that is that overloaded will be unresponsive and concentrate on the higher priority tasks. You make this out to be a bad thing (or at least to a casual observer), when in all actuallity it's a great thing. If delivering the next frame to the GPU is more important to you than compiling the kernel, the kernel will get starved. In Linux and other non-RTOS's, you will run out of time slices because they are being "fair".
This reminds me of the whole VM issue. If you don't have enough memory to complete a job, no VM you have is gonna help you. Likewise, if you don't have enough CPU to complete the job, no schedular is going to help. Where the new VM and RTOS's help is when you are playing your FPS game, you can schedule regular intervals to fill the audio buffer and calculate the next frame as well as do physics calculations. If you don't have enough CPU to do them all, pick the ones that matter most. Linux can pick them in the wrong order and miss a more important calculation getting done on time. No one has actually tested if linux can do more overall because of this, but most of us have a select few tasks actively interacting with us that we would really like to not be interrupted. RTOS can guarantee this at the sake of other processes, but that's a good thing. Win3.1 on the other hand, one unimportant process can not relenquish the CPU.
I can't get to the article, but it seems to me that Sun's veto power is over the standard. If you want to implement something strange in your GPL'd version of Java, of course it's not gonna be Java anymore:) The JCP is where you air your complaints with Java, and a lot of the times, if it's not a crackpot idea (IE other developers agree), then you can get it included in all JRE's next round.
SUN is moving toward a free certifacation test for non-profit organizations so that GPL'd programs can become certified. I think JBoss is proof that even though SUN hates that you exist, they see your right to make a GPL'd version of their specs. If you want to GPL a java implementation, you can. There has never been a problem with that. SUN has a problem when you call it Java and it isn't. Basically, they get upset when you infringe on their trademark. There are a lot of things out there now that are GPL'd and they are implementations of java. They aren't good yet, but that's because people like you spread FUD that SUN will come get you if you do it. More than likely, they would only tell you to not call it Java. Kaffe is a good example.
I think it's absolutely reasonable that SUN, where java was invented and where people truely understand java work, gets a veto power of the technology implementing new features. The number one reason I think this is that they are almost the only one implementing these new features. No one on the market but SUN has a 1.4 JVM. If you make up a feature that is gonna take a year to implement they should be able to veto it being included with the next iteration. This way you have a balance of power between developers who need features and the poor souls who have to make them work!
In my previous post I meant to say that the data isn't cached on the client, BMP/CMP is cached on the server.
hehe... but fat key design isn't exactly up to best practices though.:) I never thought about the stateful session bean idea you mention. That's very clever. If ever my data access model doesn't fit Entity Beans, I'll be doing that:) Right now, people loading a bean(avg 10 stddev 10 so 70% chance 20) will usually end up changing it or accessing it again in the very near future.
Yeah... that's driving my crazy too. Does no one understand what BMP means? It's slower because it is uncached AND there is a seperate call to the database for each row + 1 to get the keys. I don't care if it was writtin in assembler, that's gonna be SLOW!:) Then on the MS side, they cache data as well as 1 big SQL statement to return rows. That's about as fair as comparing the P4 to the Athlon when the Athlon has L2 cache turned off. Yet the parent poster doesn't see the obvious and gets modded up knowing nothing about the technologies at hand. And what's worse is they had to go out of their way to make it BMP, because CMP is so much easier. No legitamit claim will ever use BMP.
It's a demo of how the API's work, and how they work together. It's not meant for you to cut-and-paste to your own enterprise system. You have to design an enterprise system. Alan Cox is a great programmer, but you couldn't clone him 5 times and have the 6 of them just sit down and make an enterpise application. If there was a best way to do enterprise programming, there would be a wizard and all you enter is some VB code that computes the tax for area or some such. It's a set of bloody tools. You use them the way that you need them. The demo is so you don't use a monkey wrench to drive a nail, that's all.
Entity beans are good! BMP Entity beans are bad. They have always been bad. You use them when you can't use CMP. If you really want speed, you use JDBC directly in the session beans. Stateful session beans are bad. Only use them if you can't use Stateless session beans. How hard is it to understand that each one is relatively bad to another, but if you should run into a problem using one, you still have the good old sledge-a-matic that will do the job for a price.
Which brings another point to the table actually. J2EE is a spec, not a product. It makes no sence to say that J2EE is slow. There are no implementations of J2EE using Java's new asyncronous IO (NIO) libraries. Someone implemnted a webserver using NIO and it blew away Apache performance as well at raw serving. Of course it was so fast that it had to be run on a loopback interface so it doesn't matter at all. The big performance hit this takes is to the database. The DBMS in this Java version requires an SQL statement to return all the keys, and then one to retrieve each line from the DB. It doesn't have to be that way, it just is because they are dumb appearantly:) The SQL server has to parse the SQL for every single statement. That's not exactly CPU friendly either:)
There's nothing wrong with the way they did the java pet store. The problem is that it is a pet store, not a bank:) Besides, even a bank wouldn't want to use all of J2EE. It's a HUGE technology. Some ppl call it bloat. I would call glibc a bloat because I've never used the entire library before. However, if someone didn't NEED those functions, or in this case API's/features, they wouldn't be there. SUN could have written a lot of small programs, but then developers wouldn't have seen how they can work together to perform a task.
SUN doesn't need to make a good example, developers need to RTFM or by a GOOD book to tell them when and where things SHOULD be used, not where they can. J2EE isn't for pet stores to begin with. It should have been painfully obvious to anyone that knew that J2EE was an acronym for Java 2 _Enterprise_ Edition. I don't know of anyone that has a pet storage facility such that they can mail order them or not know exactly what they have just by looking. If any of you reading this need that explained to you, or you don't see the irony/humor in choosing a Pet Store for an Enterprise demonstration, then there is no hope for in you:) You could try to get a book telling you when to use certain API's, but if you're that lacking in common sence, then a book isn't likely to help.
I see what you are saying about leading experts, but don't think that the Java programmers who made the revised pet store needed to be experts to do better than they did. It looks like it was written by a team of monkeys. One good developer is better than any quantity of monkeys. If you are looking for a technology that allows monkeys to make a working enterprise systems, then you'ld be more likely to find a pot of gold at an end of a rainbow. Seriously, you really would. It just might happen that a midget dressed in green is smelting gold there. Much more likely than a monkey writing code that could work in the enterprise.
Really... how many of us have had to trouble shoot that POS legacy system that a certified MS VB monkey with 2 years of high school wrote?
I've been using J2EE now for a while, and they made some hideous performance mistakes. The #1 mistake they made was BMP. BMP, for those of you who don't know, is an object persistance model where each object manages it's own storage. It's pretty obvious that for N rows of a database that map to N objects, you will need N SQL statements. That's just wrong and bad. Not only is it the slowest way to access the database, but it requires 10x the amount of code to work with. The other two (common) choices are CMP and JDBC in session beans (others are JDO and other ADO-ish Java API's that wrap JDBC). CMP would require 1 SQL statement to retrieve N rows, and requires no SQL be written, works on all RDBMS's, and you only have to write a skeleton object. It's about a magnitude of 3 faster than CMP. Directly connecting from the Session beans(pretty much a CORPBA object) will make you write your own SQL, but will increase performance yet further(since you can use stored procedures or just do mass updates and still maintain database independance).
The next thing they did is exclude JBoss, one of the most popular J2EE servers. It's open source, and easy to use. One can only conclude the intentionally left it out because.Net could never hold up to best price/perf. against free. JBoss may not be a speed deamon(it's not slow at all though), but if you disable debugging(on by default), use IBM JDK 1.3.0 and MySQL with innoDB, it will easily win price/performance.
After reading that TMC had taken money from MS, the only conclusion that I could come up with is that it was rigged. No real J2EE expert would ever make those mistakes. Even free E-Books on TSS will tell you not to make mistakes like that.
Basically, this really hurts the Java community to see TMC take stabs at J2EE after all it's put into it. Either that or we are to conclude that TMC is unfit for the J2EE educational services they offer. Either way, they may have helped.Net get a foothold, but they are loosing theirs fast.
Anyone that doesn't know that much about J2EE or doesn't take a look at the code will think this is like the florida recount fiasco, but it really is a legitamit claim that this version of the petstore was really written by A) a monkey, or B) a MS fundee.
It's a very visual place... there needs to be something better than HTML, or some better forms of reaching the blind. I can only imagine how hard it is to navigate the web in such conditions. You could hear and feel your way around the real world. There needs to be an equivalent for the web. TTS and telephone-like menus would be easier. I would certainly make any of my websites available in such a form.
Right now, it's like a blind man watching old projection systems that didn't have audio. Maybe they have software that describes what's going on to them, but there are no set standards to make a site disabled friendly. I think it's a good ruling as long as someone does something about it:) Which is what I think the judge had in mind.
who invented this. Actually it was a team of two. One of them was a victim of age descrimination by his work, so in his spare time, he and another guy developed this. All he could tell me is the hardest part was getting the material for the contacts to be the right size was the hardest part.(imagine worrying about a half a micron to make a good connection) The second hardest is that the underside of the chip is exposed to RF. You absolutely must buy shielded chips. The advantage of this is cheaper electronics. Glass is cheaper than PCB, especially when you don't need connectors. So watches and the like won't need the extra PCB. Keep in mind as well that glass traces are extremely hard to make more than 1 level. Usually, you have several sheets of glass with connectors on the sides instead. This makes it extremely difficult to put a 370pin CPU on one. CPU bus signals may not like the width or resistance or interference of the glass traces either.
I saw a few posts argueing about heat problems. You could still put a heatsink on the chips. PCB doesn't conduct heat all that well either. PCB's on the other hand do block more RF. And photons hitting the traces on on a PCB is less of a problem than on glass:)
All in all, it's a very neat technology and is very interesting. It will save manufacturing costs a lot, maybe even in LCD monitors/LCD TV's or even hand helds. It's not going to be used for a fast computer because the technology to put traces on glass isn't nearly as good as copper that you will find in the average PCB.
At least that was the case the last time I checked. There might be some good conductors for glass now.
Actually, I think it shows very well that AGP is not a great thing at all. If you look at FPS of random cards and compare it to the memory bandwidth of the card(not AGP bandwidth), you'll probably come to the same conclusion that I have: memory bandwidth is more important than the GPU. The major improvements in the GPU have been in conserving memory bandwidth, or width of the bus to the memory. The Geforce4TI4600 offers a 10.4GB/s bandwidth. AGP 8x is a mere 2.1GB/s. With this in mind, any time you access main memory, it is going to be 1/5th the speed of the on board memory, meaning 1/5th the performance without speculative reading or cacheing. If your working set of textures is greater than the ammount of memory on your board, you will suffer severe performance hits even at 8x. 166Mhz DDR 8byte wide memory (333 dimms) are 2.6GB/s theoretical. System memory is not fit decent graphics anyhow.
The reason why AGP will never amount to much more than a seperate bus(so it doesn't choke PCI) is that graphics vendors like NVidia and ATI will always put higher performance ram on the video card than are in the main system. Even if we had AGP32X that had a bandwidth of 10GB/s, there will be 50GB/s memory on the card, and memory too slow to even keep up with AGP on the motherboard. In the end, it may allow a developer to use a variety of textures provided that there aren't more than XMB of them in use at any given point in time. This is because you can fill the local memory with textures in less than a second. A small glitch in video that doesn't occur often isn't going to annoy most gamers if the graphics are nice.
Video memory just needs to be different. Video memory got cheaper with normal memory, but it's not:) There are lots of reasons to want to do more than 128M of textures, but there are none to use system memory for video:)
The video bandwidth to the monitor at 1280x1024x32bitx85hz(refresh) would be 6GB/s at that resolution,bit depth, and FPS(refresh). Most video cards would stretch to make that. Calculate that into the memory bandwidth of the next video card you get before you check out the FPS. See how accurate it is:)
I don't think the guy knows what he's talking about:) You never have to flush the TLB either, it just won't be very usefull to the next program. I'm 99% sure that the cache is set associative to the physical address of ram, not the virtual address. The TLB was invented (AFAIK) to help mostly with pre-cache translations, so that the processor isn't waiting on translations before it can get cache. This may not be accurate L1 though.
Hey, if your vote isn't going to count, why not sell it?:)
I just hate the vote buying system we have now. Every few years a motion is brought up to do away with gift giving to representatives, but it keeps getting shot down. In America, the people get one vote (house of rep.), the land get's a vote (electorial college), and the money gets a vote (lobeying). I thought the government was for and by the people? It's really for and by the sum of people, land, and money. If you have all three, you can win. Gore had people, Bush had land, and they both had money. Turns out, land one last election. (or almost did)
How about a government where the people's opinions matter more than 6 months a year? With modern communication and transportation, the electorial college is pointless. (The original arguement was that states required independance because of localized beliefs.)
I think that's only true on platforms that opted to not have it so. Most devices out there run Java natively. (where most devices is quantity of different models, not including the popularity of some out there) A lot of the newer phones have a java implementation in the hardware directly. They don't run a VM. The handhelds mostly are run from a VM-ish thing. Not that Java can't be compiled for a set of cheap hardware already on the market. You can do completely Java embedded programming that runs natively on hardware that isn't expensive. There are smart cards that run Java natively. It would be incredible stupid of me to have said that all embedded devices can run java natively. I just assumed that the reader would interpret that as that the hardware does exist, is popular, and is competively priced with non-Java hardware.
That arguement aside, I could probably write an entire OS in Java and compile it down to x86 code. SUN should really consider the merits of writting a JVM in Java. They can then distribute a tool to translate Java code to native instructions. They already do this with their jit, they now only need to do it with a stand alone tool. It's all OK though, because Gnu is doing similar things for them, and there are already commercial products that will convert any SWT project into native binaries that need no JVM.
I'm sorry for any confusion or misleading statements. Keep in mind, though, that java is a language as well as a platform. GCJ will compile Java 1.1 compliant code into a linux elf binary. No real difference than C++ there, and it will have the same performance, close anyhow, to C++. If you are interested in using Java for an embedded application consider both alternatives (GCJ and Java hardware) for one that fits your needs better. It is viable.
about complex GUI's is: don't!:) I still like pov-ray because I can just enter what I want in a text editor rather than a modeler like 3D-S. Several smaller GUI's built for specific purposes would probably be better than one big GUI. Just break the GUI down into easy ways to do specific tasks. Try to have a consistancy among them. Really, this would be a great place to put object-oriented methods to use. Make consistant components that are groups of other UI elements. It's easy to do in Java using interfaces, but you can do it in C++ as well with inheritence and virtual functions, or call-back functions in C(ech!). I'm sure.Net has a sane way to do it(err, no I'm not really... they probably want you to drag components to a form and use cut and paste, but then you have to update every component to fix a bug, add font settings, etc.), but I really don't know. Any GUI architecture worth it's size in bits has some kind of control grouping whether it's OO, or just faking OO.
Yeah, that may be true. I'm not clear on how far the rights go for people hacking for interoperability. Reverse engineering, AFAIK, is allowed for this particular purpose. It's not breaking copyright laws still if you are allowed the one backup copy. That should hold true for BIOS as well. If you have to alter your backup copy to make it work, then that seems like reverse engineering for interoperability to protect a right that shouldn't have been taken away to begin with. What they could do and get away with is have people send in thier old bios chips and they could destroy them/fix them and send them back a fixed bios. It would be like me taking a book, converting it to brail(or an ebook), and sending it back. It shouldn't be a big deal for me to just distribute the ebook itself to people that have the book if there was a way to ensure that they had the book. The law is iffy here. Who breaks the law, the guy who lies to get the software, or the guy who takes the other by his word and sends it to him. It seems to be the later, but logically, I think it should be the first. The person actually getting the benefit of the operation is the first, and only he has a motive.
I hate law:) Eventually I'll have to go to law school and try to make a dent in the stupidity.
Actually, call them "Backup disk players" because they allow you to play your one backup copy in case the first is broken.:) You should have a legal right to backup your software, and to use that backup copy should the first be destroyed. I think reverse engineering is even legal for interoperability, so probably no problem there.
Slashdot Mirror
There will never be an end. Irresponsible programming is even less a fad than XP :)
Shouldn't a programmer that wanted to be most efficient start with the highest level of abstractions and work his/her way down as needed?
Abstraction brings effeciency (not in raw cycles but in programming time), portability, and other freedoms. In java, the hardware itself is abstracted so that buffer overflows and other security concerns aren't a problem. C programmers blame buffer overflows on poor programming. I have to ask myself who these people are. If they are so good, then they must have some popular program, right? A program like Bind or Sendmail, perhaps? Even the linux kernel has had buffer overflows.
Abstraction doesn't cost much by the way of performance. Java's abstraction is down from it's initial 1600% to 200% the speed of C. During that time C has went from it's 200% of assembler to closer to 100%. It's reasonable to foresee in the future that any abstraction, even those so severe as the JVM, will eventually aproach native speeds through optimized compilers/JIT/AOT.
The best thing about abstractions in the open source world is that a group of people who use these everyday will be the one's developing them. They will address the issues that matter to developers, and they will only need be addressed once. You don't have to reinvent the wheel when you design your car. If someone makes a better wheel, it's very likely that you will benefit from it if you use an abstraction.
Imagine the nightmare of converting to IPv6 if most people didn't use (at least portions of) the BSD TCP/IP stack??? Compare that to the trivial gains you get by not using it! What if all programers decided to use raw sockets to remove the leaky abstraction?
Fix the abstraction, don't abandon it. Have blocking TCP/IP sends (along side the others) for people that need to know if packets made it. You could just add a function to ask the system if the TCP packet had been sent yet (where sent really meant that an ack was recieved). You get to keep the interface. By the time the interface isn't leaky, you will have a large interface that performs all the tasks of the original, just in a more human comprehensible way.
Another advantage to abstractions is that they can be faster in the end. OpenGL is an abstraction. It's so popular that video card designers will work hard to make that abstraction as thin as possible. Now we have cards that support directly some or all of the functions. It's cross-platform as well because of it is an abstraction.
Don't abandon abstractions because they are slow or aren't all encompassing. Fix the leak, don't toss out the toilet.
You seem to define fad in an odd way. You suggest that anything that comes then goes is a fad. To the average person, I would asume that fad meant that it came and went without any effect. You are assuming that in Stage 3 that the original item didn't effect the building of the next best thing. Object-Oriented programming is based on procedural programming. Eventually, it could become that procedural programming is abandoned, but will not have been a fad because it's "replacement" is a derivative of the original.
I think XP is great because it was the first system designed to teach how to program responsibly. I'm sure it will be replaced by something better, because AFAIK, no one has pioneered perfection in a new field in their first shot. You can bet the farm that the next "fad" will be based on XP. I think you are afraid to change the programming methodologies you already have; therefore, from your point of view, no programming methodology will be more than a fad, because it's not yours and you will never adopt it.
BTW, I've never heard of anyone saying that peicemeal approaches to XP won't work. I've heard the exact oposite. Some people implemnt pair programming, some have great programmers they can depend on (the reasons for pair programming are so that one can catch the others errors, one may leave and someone will need to take over for him). A lot of people implement the test units because no coder is perfect and the synergy of a large system of object (be they libraries or classes) can cause one small change to break a lot of the system. In a large system, you can't remember every little thing you should test and it would be very time consuming to test them by hand.
All things die to give way for the next generation. That doesn't make yesterday's champions fads, but rather old heros.
did anyone else think the song sounded a LOT like bond theme music?
That only works with ext2/3 filesystems. Most ppl don't use those anymore. You can however resive the fs before you do such evil to it and it work, but it's still not useful in a hetrogenious network.
:) You can use |gzip -c| to compress data, and you can use xfsdump/restore to work with active systems.
:) I know it's goofy, but it's more just me playing to learn than an actual need. I want to play with gcj too, so we'll see how that turns out :) I know, I could have done it in C and put it on a floppy, but it's just more fun trying to make something wierd like that work :) Besides, it's for a school lab, there is a lot the teachers/students could learn about Java, multicasting, linux, xfs, gcj, etc. If I did C, that would be one less thing for them to learn since they already know C/C++. Few professors and students know much about java. Besides, I have a point to make about Java being good for embedded systems. I started with Lejos (java for lego bricks that I talked them into using for AI). I may try to use J2ME and put it on that open source RTOS kernel Jaluna (it has J2ME support). If J2ME and Jaluna support multicasting (Jaluna and J2ME is supposed to be able to take libraries you need and add them to the installation.) If you are counting here, now they have to learn RTOS kernels, embedded systems, and J2ME. It's a school, they'll get more than they bargained for and the end solution will be user friendly and well documented. Maybe they'll learn some UI design and good documentation habits.
If the disks are different sizes, you should partition them by hand (or set a script that uses %s).
There are multicast netpipes out there
I want to write my custom solution because then the client can just ask the server for which files are available and which groups are available and I can maximize the network utilization (just have a computer join a group and catch it up to the others while the others are throttled only if the network has been saturated.) Lilo can be configured in the script, but I prefer a block transfer of one single ext2 boot partition to the beginning of the drive and have the mbr boot that partition (set it active and use the default mbr). No problems there either. There's a lot of neat stuff I could do if I wrote my own solution, and I really just want to play with things. I've already learned a LOT about multicasting doing this (like windows machines don't support the spec properly... suprised? no, I didn't think so).
In the end I may end up with a boot floppy version, but size isn't important to me. That's why I'm playing around with it in Java
oh, I wasn't knocking bart :) It's great for what it does. It just wasn't made for what I need to do :) I considered patching bart to do it, but decided to just use nfsroot so I wouldn't have to make an endless supply of CD's :)
:) Then I can use it as example real world multicasting code for classes as well.
If you are looking for a single machine or small numbers of machines to do backup and restore, bart and g4u are great! I used g4u when my lab was homogenous, and it was perfect. I still need multicasting and tar or xfsdump support that is user friendly. It's best I write my own
If the target is 1 sector less, you aren't going to be able to use this tool. I still think tar and netpipes is the only way. (unless you use XFS, in such case the best way would be xfsdump, tar, and xfsrestore) I'm trying to write a multicast fileserver for just this purpose. I have a lab of hetrogeneous machines(I take what I can get from the university) that need to be clones(btw, don't forget to run lilo if you use tar/xfs, and don't forget to change the site-key for ssh). I'm ending up using a homebrew solution. There are other good ghost utilities out there that boot from a cdrom(BART perhaps isn't bad), but I still need my own custom solution because I'm not gonna be here forever to make this lab work, and it needs to be "put this in the floppy drive and select options from the menu" easy.
I don't know what you are talking about. How could one starve another in a RTOS? Hard deadlines are set. Most of the time, the process with the closest deadline is selected (some have time estimates and do other optimizations). If a task doesn't complete by it's deadline, it can get preempted because completing the task was just not possible. In effect, you overloaded the system therefore it is unresponsive. AFAIK, any system that is that overloaded will be unresponsive and concentrate on the higher priority tasks. You make this out to be a bad thing (or at least to a casual observer), when in all actuallity it's a great thing. If delivering the next frame to the GPU is more important to you than compiling the kernel, the kernel will get starved. In Linux and other non-RTOS's, you will run out of time slices because they are being "fair".
This reminds me of the whole VM issue. If you don't have enough memory to complete a job, no VM you have is gonna help you. Likewise, if you don't have enough CPU to complete the job, no schedular is going to help. Where the new VM and RTOS's help is when you are playing your FPS game, you can schedule regular intervals to fill the audio buffer and calculate the next frame as well as do physics calculations. If you don't have enough CPU to do them all, pick the ones that matter most. Linux can pick them in the wrong order and miss a more important calculation getting done on time. No one has actually tested if linux can do more overall because of this, but most of us have a select few tasks actively interacting with us that we would really like to not be interrupted. RTOS can guarantee this at the sake of other processes, but that's a good thing. Win3.1 on the other hand, one unimportant process can not relenquish the CPU.
Only if they show that they have been linked to piracy before. Elsewise, it looks like MS could be fined or sued if they try to do that.
I can't get to the article, but it seems to me that Sun's veto power is over the standard. If you want to implement something strange in your GPL'd version of Java, of course it's not gonna be Java anymore :) The JCP is where you air your complaints with Java, and a lot of the times, if it's not a crackpot idea (IE other developers agree), then you can get it included in all JRE's next round.
SUN is moving toward a free certifacation test for non-profit organizations so that GPL'd programs can become certified. I think JBoss is proof that even though SUN hates that you exist, they see your right to make a GPL'd version of their specs. If you want to GPL a java implementation, you can. There has never been a problem with that. SUN has a problem when you call it Java and it isn't. Basically, they get upset when you infringe on their trademark. There are a lot of things out there now that are GPL'd and they are implementations of java. They aren't good yet, but that's because people like you spread FUD that SUN will come get you if you do it. More than likely, they would only tell you to not call it Java. Kaffe is a good example.
I think it's absolutely reasonable that SUN, where java was invented and where people truely understand java work, gets a veto power of the technology implementing new features. The number one reason I think this is that they are almost the only one implementing these new features. No one on the market but SUN has a 1.4 JVM. If you make up a feature that is gonna take a year to implement they should be able to veto it being included with the next iteration. This way you have a balance of power between developers who need features and the poor souls who have to make them work!
In my previous post I meant to say that the data isn't cached on the client, BMP/CMP is cached on the server.
:) I never thought about the stateful session bean idea you mention. That's very clever. If ever my data access model doesn't fit Entity Beans, I'll be doing that :) Right now, people loading a bean(avg 10 stddev 10 so 70% chance 20) will usually end up changing it or accessing it again in the very near future.
hehe... but fat key design isn't exactly up to best practices though.
Yeah... that's driving my crazy too. Does no one understand what BMP means? It's slower because it is uncached AND there is a seperate call to the database for each row + 1 to get the keys. I don't care if it was writtin in assembler, that's gonna be SLOW! :) Then on the MS side, they cache data as well as 1 big SQL statement to return rows. That's about as fair as comparing the P4 to the Athlon when the Athlon has L2 cache turned off. Yet the parent poster doesn't see the obvious and gets modded up knowing nothing about the technologies at hand. And what's worse is they had to go out of their way to make it BMP, because CMP is so much easier. No legitamit claim will ever use BMP.
It's a demo of how the API's work, and how they work together. It's not meant for you to cut-and-paste to your own enterprise system. You have to design an enterprise system. Alan Cox is a great programmer, but you couldn't clone him 5 times and have the 6 of them just sit down and make an enterpise application. If there was a best way to do enterprise programming, there would be a wizard and all you enter is some VB code that computes the tax for area or some such. It's a set of bloody tools. You use them the way that you need them. The demo is so you don't use a monkey wrench to drive a nail, that's all.
Entity beans are good! BMP Entity beans are bad. They have always been bad. You use them when you can't use CMP. If you really want speed, you use JDBC directly in the session beans. Stateful session beans are bad. Only use them if you can't use Stateless session beans. How hard is it to understand that each one is relatively bad to another, but if you should run into a problem using one, you still have the good old sledge-a-matic that will do the job for a price.
Which brings another point to the table actually. J2EE is a spec, not a product. It makes no sence to say that J2EE is slow. There are no implementations of J2EE using Java's new asyncronous IO (NIO) libraries. Someone implemnted a webserver using NIO and it blew away Apache performance as well at raw serving. Of course it was so fast that it had to be run on a loopback interface so it doesn't matter at all. The big performance hit this takes is to the database. The DBMS in this Java version requires an SQL statement to return all the keys, and then one to retrieve each line from the DB. It doesn't have to be that way, it just is because they are dumb appearantly :) The SQL server has to parse the SQL for every single statement. That's not exactly CPU friendly either :)
There's nothing wrong with the way they did the java pet store. The problem is that it is a pet store, not a bank :) Besides, even a bank wouldn't want to use all of J2EE. It's a HUGE technology. Some ppl call it bloat. I would call glibc a bloat because I've never used the entire library before. However, if someone didn't NEED those functions, or in this case API's/features, they wouldn't be there. SUN could have written a lot of small programs, but then developers wouldn't have seen how they can work together to perform a task.
:) You could try to get a book telling you when to use certain API's, but if you're that lacking in common sence, then a book isn't likely to help.
SUN doesn't need to make a good example, developers need to RTFM or by a GOOD book to tell them when and where things SHOULD be used, not where they can. J2EE isn't for pet stores to begin with. It should have been painfully obvious to anyone that knew that J2EE was an acronym for Java 2 _Enterprise_ Edition. I don't know of anyone that has a pet storage facility such that they can mail order them or not know exactly what they have just by looking. If any of you reading this need that explained to you, or you don't see the irony/humor in choosing a Pet Store for an Enterprise demonstration, then there is no hope for in you
I see what you are saying about leading experts, but don't think that the Java programmers who made the revised pet store needed to be experts to do better than they did. It looks like it was written by a team of monkeys. One good developer is better than any quantity of monkeys. If you are looking for a technology that allows monkeys to make a working enterprise systems, then you'ld be more likely to find a pot of gold at an end of a rainbow. Seriously, you really would. It just might happen that a midget dressed in green is smelting gold there. Much more likely than a monkey writing code that could work in the enterprise.
Really... how many of us have had to trouble shoot that POS legacy system that a certified MS VB monkey with 2 years of high school wrote?
I've been using J2EE now for a while, and they made some hideous performance mistakes. The #1 mistake they made was BMP. BMP, for those of you who don't know, is an object persistance model where each object manages it's own storage. It's pretty obvious that for N rows of a database that map to N objects, you will need N SQL statements. That's just wrong and bad. Not only is it the slowest way to access the database, but it requires 10x the amount of code to work with. The other two (common) choices are CMP and JDBC in session beans (others are JDO and other ADO-ish Java API's that wrap JDBC). CMP would require 1 SQL statement to retrieve N rows, and requires no SQL be written, works on all RDBMS's, and you only have to write a skeleton object. It's about a magnitude of 3 faster than CMP. Directly connecting from the Session beans(pretty much a CORPBA object) will make you write your own SQL, but will increase performance yet further(since you can use stored procedures or just do mass updates and still maintain database independance).
.Net could never hold up to best price/perf. against free. JBoss may not be a speed deamon(it's not slow at all though), but if you disable debugging(on by default), use IBM JDK 1.3.0 and MySQL with innoDB, it will easily win price/performance.
.Net get a foothold, but they are loosing theirs fast.
The next thing they did is exclude JBoss, one of the most popular J2EE servers. It's open source, and easy to use. One can only conclude the intentionally left it out because
After reading that TMC had taken money from MS, the only conclusion that I could come up with is that it was rigged. No real J2EE expert would ever make those mistakes. Even free E-Books on TSS will tell you not to make mistakes like that.
Basically, this really hurts the Java community to see TMC take stabs at J2EE after all it's put into it. Either that or we are to conclude that TMC is unfit for the J2EE educational services they offer. Either way, they may have helped
Anyone that doesn't know that much about J2EE or doesn't take a look at the code will think this is like the florida recount fiasco, but it really is a legitamit claim that this version of the petstore was really written by A) a monkey, or B) a MS fundee.
It's a very visual place... there needs to be something better than HTML, or some better forms of reaching the blind. I can only imagine how hard it is to navigate the web in such conditions. You could hear and feel your way around the real world. There needs to be an equivalent for the web. TTS and telephone-like menus would be easier. I would certainly make any of my websites available in such a form.
:) Which is what I think the judge had in mind.
Right now, it's like a blind man watching old projection systems that didn't have audio. Maybe they have software that describes what's going on to them, but there are no set standards to make a site disabled friendly. I think it's a good ruling as long as someone does something about it
who invented this. Actually it was a team of two. One of them was a victim of age descrimination by his work, so in his spare time, he and another guy developed this. All he could tell me is the hardest part was getting the material for the contacts to be the right size was the hardest part.(imagine worrying about a half a micron to make a good connection) The second hardest is that the underside of the chip is exposed to RF. You absolutely must buy shielded chips. The advantage of this is cheaper electronics. Glass is cheaper than PCB, especially when you don't need connectors. So watches and the like won't need the extra PCB. Keep in mind as well that glass traces are extremely hard to make more than 1 level. Usually, you have several sheets of glass with connectors on the sides instead. This makes it extremely difficult to put a 370pin CPU on one. CPU bus signals may not like the width or resistance or interference of the glass traces either.
:)
I saw a few posts argueing about heat problems. You could still put a heatsink on the chips. PCB doesn't conduct heat all that well either. PCB's on the other hand do block more RF. And photons hitting the traces on on a PCB is less of a problem than on glass
All in all, it's a very neat technology and is very interesting. It will save manufacturing costs a lot, maybe even in LCD monitors/LCD TV's or even hand helds. It's not going to be used for a fast computer because the technology to put traces on glass isn't nearly as good as copper that you will find in the average PCB.
At least that was the case the last time I checked. There might be some good conductors for glass now.
Actually, I think it shows very well that AGP is not a great thing at all. If you look at FPS of random cards and compare it to the memory bandwidth of the card(not AGP bandwidth), you'll probably come to the same conclusion that I have: memory bandwidth is more important than the GPU. The major improvements in the GPU have been in conserving memory bandwidth, or width of the bus to the memory. The Geforce4TI4600 offers a 10.4GB/s bandwidth. AGP 8x is a mere 2.1GB/s. With this in mind, any time you access main memory, it is going to be 1/5th the speed of the on board memory, meaning 1/5th the performance without speculative reading or cacheing. If your working set of textures is greater than the ammount of memory on your board, you will suffer severe performance hits even at 8x. 166Mhz DDR 8byte wide memory (333 dimms) are 2.6GB/s theoretical. System memory is not fit decent graphics anyhow.
:) There are lots of reasons to want to do more than 128M of textures, but there are none to use system memory for video :)
:)
The reason why AGP will never amount to much more than a seperate bus(so it doesn't choke PCI) is that graphics vendors like NVidia and ATI will always put higher performance ram on the video card than are in the main system. Even if we had AGP32X that had a bandwidth of 10GB/s, there will be 50GB/s memory on the card, and memory too slow to even keep up with AGP on the motherboard. In the end, it may allow a developer to use a variety of textures provided that there aren't more than XMB of them in use at any given point in time. This is because you can fill the local memory with textures in less than a second. A small glitch in video that doesn't occur often isn't going to annoy most gamers if the graphics are nice.
Video memory just needs to be different. Video memory got cheaper with normal memory, but it's not
The video bandwidth to the monitor at 1280x1024x32bitx85hz(refresh) would be 6GB/s at that resolution,bit depth, and FPS(refresh). Most video cards would stretch to make that. Calculate that into the memory bandwidth of the next video card you get before you check out the FPS. See how accurate it is
I don't think the guy knows what he's talking about :) You never have to flush the TLB either, it just won't be very usefull to the next program. I'm 99% sure that the cache is set associative to the physical address of ram, not the virtual address. The TLB was invented (AFAIK) to help mostly with pre-cache translations, so that the processor isn't waiting on translations before it can get cache. This may not be accurate L1 though.
Hey, if your vote isn't going to count, why not sell it? :)
I just hate the vote buying system we have now. Every few years a motion is brought up to do away with gift giving to representatives, but it keeps getting shot down. In America, the people get one vote (house of rep.), the land get's a vote (electorial college), and the money gets a vote (lobeying). I thought the government was for and by the people? It's really for and by the sum of people, land, and money. If you have all three, you can win. Gore had people, Bush had land, and they both had money. Turns out, land one last election. (or almost did)
How about a government where the people's opinions matter more than 6 months a year? With modern communication and transportation, the electorial college is pointless. (The original arguement was that states required independance because of localized beliefs.)
I think that's only true on platforms that opted to not have it so. Most devices out there run Java natively. (where most devices is quantity of different models, not including the popularity of some out there) A lot of the newer phones have a java implementation in the hardware directly. They don't run a VM. The handhelds mostly are run from a VM-ish thing. Not that Java can't be compiled for a set of cheap hardware already on the market. You can do completely Java embedded programming that runs natively on hardware that isn't expensive. There are smart cards that run Java natively. It would be incredible stupid of me to have said that all embedded devices can run java natively. I just assumed that the reader would interpret that as that the hardware does exist, is popular, and is competively priced with non-Java hardware.
That arguement aside, I could probably write an entire OS in Java and compile it down to x86 code. SUN should really consider the merits of writting a JVM in Java. They can then distribute a tool to translate Java code to native instructions. They already do this with their jit, they now only need to do it with a stand alone tool. It's all OK though, because Gnu is doing similar things for them, and there are already commercial products that will convert any SWT project into native binaries that need no JVM.
I'm sorry for any confusion or misleading statements. Keep in mind, though, that java is a language as well as a platform. GCJ will compile Java 1.1 compliant code into a linux elf binary. No real difference than C++ there, and it will have the same performance, close anyhow, to C++. If you are interested in using Java for an embedded application consider both alternatives (GCJ and Java hardware) for one that fits your needs better. It is viable.
about complex GUI's is: don't! :) I still like pov-ray because I can just enter what I want in a text editor rather than a modeler like 3D-S. Several smaller GUI's built for specific purposes would probably be better than one big GUI. Just break the GUI down into easy ways to do specific tasks. Try to have a consistancy among them. Really, this would be a great place to put object-oriented methods to use. Make consistant components that are groups of other UI elements. It's easy to do in Java using interfaces, but you can do it in C++ as well with inheritence and virtual functions, or call-back functions in C(ech!). I'm sure .Net has a sane way to do it(err, no I'm not really... they probably want you to drag components to a form and use cut and paste, but then you have to update every component to fix a bug, add font settings, etc.), but I really don't know. Any GUI architecture worth it's size in bits has some kind of control grouping whether it's OO, or just faking OO.
Yeah, that may be true. I'm not clear on how far the rights go for people hacking for interoperability. Reverse engineering, AFAIK, is allowed for this particular purpose. It's not breaking copyright laws still if you are allowed the one backup copy. That should hold true for BIOS as well. If you have to alter your backup copy to make it work, then that seems like reverse engineering for interoperability to protect a right that shouldn't have been taken away to begin with. What they could do and get away with is have people send in thier old bios chips and they could destroy them/fix them and send them back a fixed bios. It would be like me taking a book, converting it to brail(or an ebook), and sending it back. It shouldn't be a big deal for me to just distribute the ebook itself to people that have the book if there was a way to ensure that they had the book. The law is iffy here. Who breaks the law, the guy who lies to get the software, or the guy who takes the other by his word and sends it to him. It seems to be the later, but logically, I think it should be the first. The person actually getting the benefit of the operation is the first, and only he has a motive.
:) Eventually I'll have to go to law school and try to make a dent in the stupidity.
I hate law
Actually, call them "Backup disk players" because they allow you to play your one backup copy in case the first is broken. :) You should have a legal right to backup your software, and to use that backup copy should the first be destroyed. I think reverse engineering is even legal for interoperability, so probably no problem there.