Please mod that guy up or the parent down. Package management is a completely irrelevant problem.
These are actually important questions:
How long will it take them to cut GTK support?
What does this mean for Nokias Qt support? Many people in the Qt community have been worried that they would cut back on the desktop support in favour of the mobile parts.
Intel controlling a Linux distro? How does this fit into the larger picture? How does this affect the possibility of it getting into the phones from, say, Motorola?
Package management is irrelevant because it is not a general purpose system. So packages of software built for this won't be installed on Debian anyway - why worry about it?
Sorry, but no you don't. You can easily use some set of modifiers for it instead. Win-space does nothing on my machine and is even easier to get to than SysRq because you don't have to move your hands from the normal position.
If the journalists would actually have bothered looking at the last years numbers from Lego, they would have seen that the turnaround is due to a much much lower cost than ten - fifteen years ago. Their revenue numbers have been pretty stable for the last twenty years. But they spend *half* what they did in the mid ninetees.
This is the reason Lego has become profitable again. Not Hollywood.
Although I can see why stupid journalists would prefer the other story. *sigh*
There are problems, where fortran is a better (or at least probably a faster runtime) solution. But teaching fortran to every undergraduate would be a big mistake.
They should be taught how to program, not how to do it in fortran. (And if you don't understand the difference here, you don't understand the problem.) Use any kind of language that is easy to teach and learn, or something that is used regularly out there.
Anyone programming fortran or cobol (same issue, just with banking instead of physics) will tell you that it takes about three weeks to teach a decent programmer how to do this language as well. But if you start out by teaching them the old school stuff, there is almost no way to get them up to speed on todays programming styles.
So teach them how to do proper programming, and make specialized courses for those very few who needs the legacy languages.
There is a solution to your situation, and it even lets you stay with KOrganizer. Here's the setup:
Postfix and Cyrus imapd on the server. This is the part that gives you a single place to hold all your email, calendar and contacts and share access with others.
On the client side, you use KMail to access the imap server. Hint: Use disconnected IMAP instead of online IMAP - it's just better. In KMail setup, you go to misc->groupware, activate the IMAP resource functionality, and set your IMAP inbox as the place you hold the things. This gives you a set of subfolders that will hold the contacts, calendar items, notes, and todos. Sync your mail account. Right click on the calendar folder, choose properties, access control, and add your secretary.
Go to the KDE control center and choose KDE components->KDE resources. For contacts, calendar and notes you now add the imap resource and remove the other resources.
Now start up Kontact or the individual apps, and reimport your saved calendar and contacts.
When your secretary accesses the imap server, he/she will get access to your calendar/contacts folder (if you gave that access). He needs to set the properties on the folders and choose the contents to be calendar/contacts/whatever and to also do the resources and IMAP groupware setup.
It's so complicated to do the initial setup, but it actually works really well. I was part of the team that wrote all of this as part of the Kolab project, and I've used it for almost four years now.
It's even possible to share calendar, mail and contacts with Outlook users, but that's a longer story.
I hope it will help you and others.
Bo Thorsen, Thorsen Consulting. www.thorsen-consulting.dk - Qt expert services.
I've been making a living contract coding C++ and Qt for about four years now. I've also used Java, PHP, python, and a couple of other languages for various projects. I really like Java as a language, I think PHP is pretty nice and useful and I absolutely adore python. But the C++/Qt combo is what I enjoy most.
I'm very much into cross platform - usually all my projects have to run on Linux and Windows. My experience from this tells me it's not more difficult to do in C++/Qt than it is in Java, but you need to know what to avoid. The Java saying "write once, compile anywhere" is marketing bs. Java apps needs porting, just like anything else. It's even worse for.NET, where Mono only implements part of the environment.
I also work a lot in embedded devices, and in this area the Java and.NET are almost non-existing. Why? Performance. These systems are based on slow processors and always too little memory. But with a little extra care, I can use the same C++/Qt combo to solve the projects here.
Another case where performance mattered: I got a contract to port a.NET application to Qt (this was one of the rare Windows only contracts) because the performance of the.NET app was so horrible it was going to be rejected by users. And the Microsoft engineers who helped this company solve the issues kept saying "the next version will fix all your problems". Well, after three new versions that didn't fix anything, they decided to get rid of.NET and hired my company to rewrite it in Qt. And they are incredibly happy with the result. The application outperforms the old.NET app in every single way. Even on large workstations. For this company, managed code is something they might look at again in some distant future.
The one thing that can get more complicated with native code is deployment. The Java way of packing everything in a single jar file often works really well. With native code you have to care about library versions, binary compatibility, and different OS versions. This is a real problem, that managed code has much better answers to.
My experience is that it is not more difficult to write code in native C++/Qt than in Java. The outcome of it is more difficult to install and deploy, but after it is solved, you will get an application that has a better look'n'feel to it.
Fantastic! Now we'll have a bunch of open movie zealots going "the only right and secure way to watch a movie is to render it yourself".
And someone can give a fantastic speech about embedding the attack into the movie "compiler".
Re:KDE, Gnome, or: Why Linux is going down the dra
on
Why KDE Rules
·
· Score: 3, Interesting
The author of this comment is missing something: KDE is not a Linux only desktop. Try forgetting about Linux completely and think Solaris or FreBSD - or even Windows, and read it again.
I was using KDE on Solaris a while back, and it was every bit as powerful as it is on my Linux boxes. And that is because KDE does not use all sorts of Linux only technologies.
This isn't the full picture, though. In many cases, KDE will use the enhanced options of your OS, and provide backups for other systems. A simple example: Monitoring directories and files for changes. Linux (and possibly others) have a system that does notifications from the filesystem when something changes. For systems that can't do this, there is a polling implementation.
And in other situations, KDE will use extra features of your system. X extensions like render comes to mind.
And you mention FUSE - this is actually the KDE IO system that is exported like filesystems. That's a very nice idea, but it sort of goes against the argument that KDE reinvents this wheel.
KPPP was for a very long time a frontend to a command line ppp tool. But this turned out to not be powerful enough to be useful. If you start doing these frontends (and I actually have), you very soon run into situations where the reporting from them is too simple. One example is that GUI apps have progressbars for long running "things" - almost no text app provides a hook for GUI frontends to provide this. And you *always* have to parse whatever text is output to the user and present this in a GUI - and you can bet on this text to be different between every single release, and that your application is running on 117 different distros that have 117 different versions of your backend app. This means you have to figure out what version of the backend app this currently is, and parse the right one.
Now, add the multiple OS problem from above. Either you have to make frontends to the very different commands on FreeBSD, Solaris, h-pukes, AIX, and others, or you start adding GNU software to the requirements list of your application. Personally I hate having to install all sorts of stuff, just to run a single application.
Making frontends to text apps is often mentioned as a good idea. But that is only by people who have not actually tried implementing and supporting one of these beasts. If it should really be done, we should start compiling all text apps as a static library, and make the text app a frontend too. Then it could potentially work - providing both the GUI and text app authors have influence on the backend library.
Sometimes reimplementing the wheel is actually a better choice.
I can see why you would think this, but it's far from the truth.
I used to work for SuSE back some years ago, and the process of going more and more open has been running since SuSE started business back in 93.
Novell does not tell SuSE what to do - they're clever enough to let the SuSE people run their own distro. And it's SuSE people that have driven both GPL'ing YaST, OpenSuSE, ISOs on the ftp server and so on.
There are quite a lot of posts here that asks some ligitimate questions, and I'll try to answer a bunch of them here.
First of all: The "Kroupware" name. Don't worry, it doesn't exist at all anymore. Kroupware was the name of the contract development, and will not be used for anything else. The server is called Kolab, and the client is KMail, Korganizer, KAddressbook and KPilot. In KDE 3.2 these will come together in one bunch under the name Kontact. We are now porting the features to KDE cvs HEAD.
Second: There are a bunch of people asking about features. For this project we had a list of requirements from BSI that we would implement. We implemented exactly this and not much more. When people say the word groupware, they immediatelly expect three thousand different functionalities, and if you in version 1.0 try to implement all of them, you will break your neck trying.
The functionality is:
Calendaring with iCalendar - send invitations between KMail and Outlook for example
Addressbook - a global one by LDAP and a local one in vCard contacts
Tasks - not groupware tasks though (only KMail to KMail or Outlook to Outlook, since OL doesn't understand iCalendar tasks scheduling:-( )
Vacation mail setup - for vacation nag mails
MDN
Disconnected IMAP support
Roaming support by storing the calendar/contacts... stuff in IMAP folders
Resource scheduling (book cars, rooms...)
I probably forgot a bunch of features. Clientwise, the most important are definately that you can invite between KMail and Outlook. On the server side, the interesting thing here is that this is the only truly free groupware server available, and will allow the Outlook people to continue working with it.
In case you visit the Linux Developers Conference in Edinburgh next week, you can see a presentation/demonstration by me.
Bo Thorsen,
Klaralvdalens Datakonsult AB
Project leader on the client.
An important article bugfix
on
Corporate KDE
·
· Score: 1
The C-Net article and the/. story both claims BSI (the German institute for secure computing or something like that) funded the kroupware project. This is not true, they contracted a solution from the three companies.
The difference really is important. Most important, it would be illegal for German government agencies to support a direct competitor to commercial applications with sponsoring development of free software. This means that if the public sees this contract as a funding of KDE, there won't be more contracts. The KDE community have enjoyed some great enhancements to especially KMail because of these contracts, so it would be really sad if it had to stop.
We won a contract to produce a groupware solution, which we're currently very close to finishing. The second server beta was put out by Erfrakon during this week, and tomorrow (Danish time) I'll put out the first client beta.
And another thing: The name "Kroupware" is just the contract name - it will not be used in KDE. We made a lot of enhancements in (and glue between) the different PIM applications in KDE, and there won't be any application named Kroupware. There will be one called "Kontact" which puts the components together in a single application, but it will still be possible to use all of them individually - even while still having all the groupware functionality.
Bo Thorsen, Kroupware KDE client project manager, Klaralvdalens Datakonsult AB.
One more reason for Hollywood to fight piracy at all fronts.
The thiefs releasing this gives everyone else a much harder time fighting against DMCA and laws like it.
This is an area where "information wants to be free" doesn't apply. We need to see these piraters as thieves and nothing less. They do no good and only push the companies into lobbying more for greater control over all normal people - which is because the big companies are morons and doesn't realize that the law won't protect against the thieves.
Yeah, I know. I'll probably be modded down below trolling.
The whole point of a console like the X-Box is that they have complete control over what they can do with it. Why on earth should they care if or if not someone uses the box to run something else on?
Face it guys, the reason the changed something was because they wanted to, and they don't give a shit about caring for the X-Box hackers compatibility. And, might I add, they shouldn't do so. If you want a PC, buy a PC - an X-Box is not a general purpose machine.
I can't stand MS anymore than most others here, but this story is absolute bullshit. Fight them where the battle is at, not just everywhere.
This is slightly off-topic and a shameless plug, but it might be interesting to people visiting Linux Tag.
I'm giving a talk saturday at 14.00 about the hammer (a.k.a. x86-64), talking about the machine and whats in it. I will also tell a lot about how the port was done, how we worked with AMD and so on.
I worked on binutils, gcc and all sorts of other porting for SuSE over the last 18 months.
If you have any questions related to the hammer on Linux, come talk to me at the show or send me an email.
There are three things that makes Linux stand out as a very good choice:
Free Software - to the company involved in robots that I used to work for, this is simply *the* selling point. It is a point that no other embedded system can do
*Very* good driver support. There simply is nowhere near the level of driver maturity in other embedded OSes
Since it's coming from a full-fledged system, you have the option of taking all the stuff off the full OS shelf. This means you can decide if you want to use TCP/IP, firewalling, X/QtEmbedded, java... The flexibility offered here is extremely good
A very good toolchain. Yes, gcc can loose very much in benchmarks against Intels or Microsofts compilers (though it still beats them in others), but compared to other RTOS compilers, it is simply so much better. The compilers are usually obscenely expensive, very buggy, and support is non-existant or equally obscenely expensive
To my former employer these points meant a lot more value than any other OS could offer.
Bo Thorsen, SuSE Labs.
Re:Two transition periods?
on
If I Had a Hammer
·
· Score: 2, Interesting
You're not oversimplifying, you're simply wrong:-) I believe the cause for your mistake is that you are listening to marketing guys without realizing it. So, some facts to set the record straight.
The definition of a 64 bit processor is that it has 64 bit adressing - 64 bit pointers. Everything else, 64 bit registers etc - is just the icing on the cake and the things you would expect.
With this in mind, it's easy to see why you're wrong. At this point in time, there does not exist enough memory in the world to fill the 64 bit addressing space. So why on earth would anyone want a larger pointer, when we don't have anything to use it for?
While I'm sure this will change at one point (since 640 kbyte really isn't enough for everyone), it doesn't make sense to build a processor for requirements that might be 20 years away.
And in case you're wondering; the so-called 128 bit processors of today are really only 32 or 64 bit processors, but since we lack the terminology for describing a processor with 64 or 128 bit registors, memory bus width, internal processing capabilities etc., the marketing dudes get away with calling them 128 bit processors.
End of dry definition.
Bo Thorsen, SuSE Labs.
Re:Compiled for 64 Bit...and Programmed for 64 Bit
on
If I Had a Hammer
·
· Score: 2, Informative
You're wrong in this.
I have been working for SuSE on porting gcc and binutils for x86-64 for over a year now, and it has been pretty painless. After we had the basic system running, I ported a fullblown but small linux system to it (sysvinit, linux-utils, vim etc.) and the only thing I had to do was to make configure scripts grok the x86_64-unknown-linux architecture.
If you take a look at the design papers on x86-64.org or amd.com, you will find that the architecture is very easy to port to. It's basically an athlon with 64 bit adressing modes on top (very simplified way of looking at it). What AMD has done is to do the exact same transition that Intel did from i286 to i386 - 16 to 32 bit.
The new architecture is impressively easy to handle, and gcc can by now optimize almost as good for x86-64 as for i386. It's really just a matter of recompiling.
And if you don't want to do that, run the 32 bit binary. The x86-64 architecture includes running i386 binaries at native speed. This is no marketing crap, it really is the same as you would expect from an athlon.
Of course, if your application has assembler in it, you have to port this. But take a look at the docs again, and you'll feel very much at home there. Actually the extra registers will give you a warm fuzzy feeling inside:-) But my point here is that there is no change in the way you think - no change in the coding philosophy.
I appreciate your point, because for a lot of platform it would be true. But on this one it simply isn't.
If there's one thing I agree with Rik Van Riel about, it's that further kernel hacking won't help Linux be adobted further.
The real problems for Linux exist in the middle layers, all the things between the kernel and KDE/GNOME. In here there is vast amounts of work that needs to be done, and way too few people doing it.
I have difficulty understanding why it is that people focus so much on kernel development, when at this point in development gcc and glibc hacking is incredibly more important. This is the bottom of the system, controlling the performance of everything. And this layer is not good enough yet.
Now, if you really want to hack on the kernel, by all means do so. Don't let anyone tell you that it's not necessary or won't do any good. Because that's not what I'm saying here. But I am saying that you would do Linux a whole lot of good by choosing a different area than the kernel.
I know; it's difficult to choose another project when sites like Slashdot only gives any attention to Kernel hackers and KDE/GNOME releases. It's difficult to live in a meritocracy when people are not giving equal merits to the different parts of the system.
Last: Whatever you choose, stick with it. The one thing Linux really needs is a bunch of people who knows a *lot* about their topic. People like me who knows something of everything are not equally valuable.
In various hacker circles we have often discussed the China market for one reason: Why don't we see more stuff coming out of China?
Red Flag Linux is one of the biggest (maybe biggest of us all) Linux distributors, but you still see nothing coming back to the society. Try to think of the last time you saw a patch from a chinese developer - it's very rare.
I would really like to see the chinese hackers contributing to the environment in the future. Then it would be really interesting how Linux is doing in China.
I work on the Sledgehammer Linux port, so I regularly compile binutils, gcc, glibc, kernel, X and other stuff on my machines. Besides compiling, I use the machines to run the simulator for the chip. I'd say I stress my machines more than most people.
I have a Ghz Athlon workstation, a Dell 850 MHz Pentium 3 based Inspiron 8000 and a GHz Mobile Athlon based Compaq 1200Z.
My workstation is between two or three times faster than both laptops. Now, how can that be when they have somewhat comparable cpus? Because of a fact that a faster cpu or graphics card can't change: The I/O subsystem in a laptop is so horrible that it's beyond comparison with our workstation I/O. And, have in mind that the x86 PCs have the worst I/O performance of all architectures. Whenever I fire up the simulator, then the laptops are pretty fast, because that is almost exclusively cpu bound. Compiling or other more full-system stuff makes the laptops crawl.
I'd say to every gamer or hacker out there: Don't buy a laptop because you think it's a desktop replacement. The overall system performance on them sucks and you will be disappointed. By a laptop if you need a mobile computer.
I have been working for SuSE Labs on the X86-64 port for about a year now, and I thought you might be interested in hearing about the state of the port.
Back in march we saw the first printf ("Hello World\n") succeed in the simulator. This is quite a big thing because it needs a working compiler, binutils, glibc and kernel. Since then we have steadily improved the system. By now we're running a full fledged Linux system in the simulator. The system is partly 64 bit and partly 32 bit. We will use the native 32 bit capabilities of the chip to use 32 bit binaries when that makes the most sense (who needs a 64 bit ls when a 32 bit ls does 64 bit filesystems fine).
By now gcc (C and C++ support), binutils, glibc, gdb, the kernel, ncurses, bash, util-linux, vim etc. have all been ported almost completely. And X runs happily in 64 bit too. Now we need the desktop systems, apache, databases etc.
Shameless plug: I'm giving a one-hour talk about Linux on X86-64 at Linux World Frankfurt next tuesday, october 30th. Here I'll show the system running, give an overview of what porting Linux is and describe the new features for Linux that we have implemented.
Please don't take this as a bad sign. SuSE is just restructuring a bit and there is absolutely no signs of the company going under or whatever other gloomy future timothy has in mind for the company.
Merging with Mandrake is a ridiculous proposition and it's incredibly bad behaviour of a journalist (or someone acting in this role) to suggest something like this.
Bo Thorsen.
Disclaimer: I work for SuSE Labs, but I speak for myself.
Slashdot Mirror
Please mod that guy up or the parent down. Package management is a completely irrelevant problem.
These are actually important questions:
How long will it take them to cut GTK support?
What does this mean for Nokias Qt support? Many people in the Qt community have been worried that they would cut back on the desktop support in favour of the mobile parts.
Intel controlling a Linux distro? How does this fit into the larger picture? How does this affect the possibility of it getting into the phones from, say, Motorola?
Package management is irrelevant because it is not a general purpose system. So packages of software built for this won't be installed on Debian anyway - why worry about it?
Bo Thorsen.
Sorry, but no you don't. You can easily use some set of modifiers for it instead. Win-space does nothing on my machine and is even easier to get to than SysRq because you don't have to move your hands from the normal position.
If the journalists would actually have bothered looking at the last years numbers from Lego, they would have seen that the turnaround is due to a much much lower cost than ten - fifteen years ago. Their revenue numbers have been pretty stable for the last twenty years. But they spend *half* what they did in the mid ninetees.
This is the reason Lego has become profitable again. Not Hollywood.
Although I can see why stupid journalists would prefer the other story. *sigh*
Bo.
There are problems, where fortran is a better (or at least probably a faster runtime) solution. But teaching fortran to every undergraduate would be a big mistake.
They should be taught how to program, not how to do it in fortran. (And if you don't understand the difference here, you don't understand the problem.) Use any kind of language that is easy to teach and learn, or something that is used regularly out there.
Anyone programming fortran or cobol (same issue, just with banking instead of physics) will tell you that it takes about three weeks to teach a decent programmer how to do this language as well. But if you start out by teaching them the old school stuff, there is almost no way to get them up to speed on todays programming styles.
So teach them how to do proper programming, and make specialized courses for those very few who needs the legacy languages.
Bo Thorsen.
Women in Denmark have larger breasts than women in Canada. There are more moose in Canada than in Denmark. So more moose means smaller breasts.
Statistics are like miniskirts; they show a lot but hide the most important facts.
There is a solution to your situation, and it even lets you stay with KOrganizer. Here's the setup:
Postfix and Cyrus imapd on the server. This is the part that gives you a single place to hold all your email, calendar and contacts and share access with others.
On the client side, you use KMail to access the imap server. Hint: Use disconnected IMAP instead of online IMAP - it's just better. In KMail setup, you go to misc->groupware, activate the IMAP resource functionality, and set your IMAP inbox as the place you hold the things. This gives you a set of subfolders that will hold the contacts, calendar items, notes, and todos. Sync your mail account. Right click on the calendar folder, choose properties, access control, and add your secretary.
Go to the KDE control center and choose KDE components->KDE resources. For contacts, calendar and notes you now add the imap resource and remove the other resources.
Now start up Kontact or the individual apps, and reimport your saved calendar and contacts.
When your secretary accesses the imap server, he/she will get access to your calendar/contacts folder (if you gave that access). He needs to set the properties on the folders and choose the contents to be calendar/contacts/whatever and to also do the resources and IMAP groupware setup.
It's so complicated to do the initial setup, but it actually works really well. I was part of the team that wrote all of this as part of the Kolab project, and I've used it for almost four years now.
It's even possible to share calendar, mail and contacts with Outlook users, but that's a longer story.
I hope it will help you and others.
Bo Thorsen,
Thorsen Consulting.
www.thorsen-consulting.dk - Qt expert services.
I've been making a living contract coding C++ and Qt for about four years now. I've also used Java, PHP, python, and a couple of other languages for various projects. I really like Java as a language, I think PHP is pretty nice and useful and I absolutely adore python. But the C++/Qt combo is what I enjoy most.
.NET, where Mono only implements part of the environment.
.NET are almost non-existing. Why? Performance. These systems are based on slow processors and always too little memory. But with a little extra care, I can use the same C++/Qt combo to solve the projects here.
.NET application to Qt (this was one of the rare Windows only contracts) because the performance of the .NET app was so horrible it was going to be rejected by users. And the Microsoft engineers who helped this company solve the issues kept saying "the next version will fix all your problems". Well, after three new versions that didn't fix anything, they decided to get rid of .NET and hired my company to rewrite it in Qt. And they are incredibly happy with the result. The application outperforms the old .NET app in every single way. Even on large workstations. For this company, managed code is something they might look at again in some distant future.
I'm very much into cross platform - usually all my projects have to run on Linux and Windows. My experience from this tells me it's not more difficult to do in C++/Qt than it is in Java, but you need to know what to avoid. The Java saying "write once, compile anywhere" is marketing bs. Java apps needs porting, just like anything else. It's even worse for
I also work a lot in embedded devices, and in this area the Java and
Another case where performance mattered: I got a contract to port a
The one thing that can get more complicated with native code is deployment. The Java way of packing everything in a single jar file often works really well. With native code you have to care about library versions, binary compatibility, and different OS versions. This is a real problem, that managed code has much better answers to.
My experience is that it is not more difficult to write code in native C++/Qt than in Java. The outcome of it is more difficult to install and deploy, but after it is solved, you will get an application that has a better look'n'feel to it.
Bo Thorsen,
Thorsen Consulting.
Fantastic! Now we'll have a bunch of open movie zealots going "the only right and secure way to watch a movie is to render it yourself".
And someone can give a fantastic speech about embedding the attack into the movie "compiler".
The author of this comment is missing something: KDE is not a Linux only desktop. Try forgetting about Linux completely and think Solaris or FreBSD - or even Windows, and read it again.
I was using KDE on Solaris a while back, and it was every bit as powerful as it is on my Linux boxes. And that is because KDE does not use all sorts of Linux only technologies.
This isn't the full picture, though. In many cases, KDE will use the enhanced options of your OS, and provide backups for other systems. A simple example: Monitoring directories and files for changes. Linux (and possibly others) have a system that does notifications from the filesystem when something changes. For systems that can't do this, there is a polling implementation.
And in other situations, KDE will use extra features of your system. X extensions like render comes to mind.
And you mention FUSE - this is actually the KDE IO system that is exported like filesystems. That's a very nice idea, but it sort of goes against the argument that KDE reinvents this wheel.
KPPP was for a very long time a frontend to a command line ppp tool. But this turned out to not be powerful enough to be useful. If you start doing these frontends (and I actually have), you very soon run into situations where the reporting from them is too simple. One example is that GUI apps have progressbars for long running "things" - almost no text app provides a hook for GUI frontends to provide this. And you *always* have to parse whatever text is output to the user and present this in a GUI - and you can bet on this text to be different between every single release, and that your application is running on 117 different distros that have 117 different versions of your backend app. This means you have to figure out what version of the backend app this currently is, and parse the right one.
Now, add the multiple OS problem from above. Either you have to make frontends to the very different commands on FreeBSD, Solaris, h-pukes, AIX, and others, or you start adding GNU software to the requirements list of your application. Personally I hate having to install all sorts of stuff, just to run a single application.
Making frontends to text apps is often mentioned as a good idea. But that is only by people who have not actually tried implementing and supporting one of these beasts. If it should really be done, we should start compiling all text apps as a static library, and make the text app a frontend too. Then it could potentially work - providing both the GUI and text app authors have influence on the backend library.
Sometimes reimplementing the wheel is actually a better choice.
I can see why you would think this, but it's far from the truth.
I used to work for SuSE back some years ago, and the process of going more and more open has been running since SuSE started business back in 93.
Novell does not tell SuSE what to do - they're clever enough to let the SuSE people run their own distro. And it's SuSE people that have driven both GPL'ing YaST, OpenSuSE, ISOs on the ftp server and so on.
"Or would you rather live in a alternate dimension, where Microsoft successfully forked Java, and we have 2 incompatible Javas?"
.NET is?
Isn't that basically what
You can see the awards won by KDE on the KDE awards page.
Bo.
First of all: The "Kroupware" name. Don't worry, it doesn't exist at all anymore. Kroupware was the name of the contract development, and will not be used for anything else. The server is called Kolab, and the client is KMail, Korganizer, KAddressbook and KPilot. In KDE 3.2 these will come together in one bunch under the name Kontact. We are now porting the features to KDE cvs HEAD.
Second: There are a bunch of people asking about features. For this project we had a list of requirements from BSI that we would implement. We implemented exactly this and not much more. When people say the word groupware, they immediatelly expect three thousand different functionalities, and if you in version 1.0 try to implement all of them, you will break your neck trying.
The functionality is:
Calendaring with iCalendar - send invitations between KMail and Outlook for example
Addressbook - a global one by LDAP and a local one in vCard contacts
Tasks - not groupware tasks though (only KMail to KMail or Outlook to Outlook, since OL doesn't understand iCalendar tasks scheduling :-( )
Vacation mail setup - for vacation nag mails
MDN
Disconnected IMAP support
Roaming support by storing the calendar/contacts... stuff in IMAP folders
Resource scheduling (book cars, rooms...)
I probably forgot a bunch of features. Clientwise, the most important are definately that you can invite between KMail and Outlook. On the server side, the interesting thing here is that this is the only truly free groupware server available, and will allow the Outlook people to continue working with it.
In case you visit the Linux Developers Conference in Edinburgh next week, you can see a presentation/demonstration by me.
Bo Thorsen,
Klaralvdalens Datakonsult AB
Project leader on the client.
The C-Net article and the /. story both claims BSI (the German institute for secure computing or something like that) funded the kroupware project. This is not true, they contracted a solution from the three companies.
The difference really is important. Most important, it would be illegal for German government agencies to support a direct competitor to commercial applications with sponsoring development of free software. This means that if the public sees this contract as a funding of KDE, there won't be more contracts. The KDE community have enjoyed some great enhancements to especially KMail because of these contracts, so it would be really sad if it had to stop.
We won a contract to produce a groupware solution, which we're currently very close to finishing. The second server beta was put out by Erfrakon during this week, and tomorrow (Danish time) I'll put out the first client beta.
And another thing: The name "Kroupware" is just the contract name - it will not be used in KDE. We made a lot of enhancements in (and glue between) the different PIM applications in KDE, and there won't be any application named Kroupware. There will be one called "Kontact" which puts the components together in a single application, but it will still be possible to use all of them individually - even while still having all the groupware functionality.
Bo Thorsen,
Kroupware KDE client project manager,
Klaralvdalens Datakonsult AB.
One more reason for Hollywood to fight piracy at all fronts.
The thiefs releasing this gives everyone else a much harder time fighting against DMCA and laws like it.
This is an area where "information wants to be free" doesn't apply. We need to see these piraters as thieves and nothing less. They do no good and only push the companies into lobbying more for greater control over all normal people - which is because the big companies are morons and doesn't realize that the law won't protect against the thieves.
Yeah, I know. I'll probably be modded down below trolling.
*sigh*
The whole point of a console like the X-Box is that they have complete control over what they can do with it. Why on earth should they care if or if not someone uses the box to run something else on?
Face it guys, the reason the changed something was because they wanted to, and they don't give a shit about caring for the X-Box hackers compatibility. And, might I add, they shouldn't do so. If you want a PC, buy a PC - an X-Box is not a general purpose machine.
I can't stand MS anymore than most others here, but this story is absolute bullshit. Fight them where the battle is at, not just everywhere.
This is slightly off-topic and a shameless plug, but it might be interesting to people visiting Linux Tag.
I'm giving a talk saturday at 14.00 about the hammer (a.k.a. x86-64), talking about the machine and whats in it. I will also tell a lot about how the port was done, how we worked with AMD and so on.
I worked on binutils, gcc and all sorts of other porting for SuSE over the last 18 months.
If you have any questions related to the hammer on Linux, come talk to me at the show or send me an email.
Bo Thorsen,
bo at suse dot de
Free Software - to the company involved in robots that I used to work for, this is simply *the* selling point. It is a point that no other embedded system can do
*Very* good driver support. There simply is nowhere near the level of driver maturity in other embedded OSes
Since it's coming from a full-fledged system, you have the option of taking all the stuff off the full OS shelf. This means you can decide if you want to use TCP/IP, firewalling, X/QtEmbedded, java... The flexibility offered here is extremely good
A very good toolchain. Yes, gcc can loose very much in benchmarks against Intels or Microsofts compilers (though it still beats them in others), but compared to other RTOS compilers, it is simply so much better. The compilers are usually obscenely expensive, very buggy, and support is non-existant or equally obscenely expensive
To my former employer these points meant a lot more value than any other OS could offer.
Bo Thorsen,
SuSE Labs.
You're not oversimplifying, you're simply wrong :-) I believe the cause for your mistake is that you are listening to marketing guys without realizing it. So, some facts to set the record straight.
The definition of a 64 bit processor is that it has 64 bit adressing - 64 bit pointers. Everything else, 64 bit registers etc - is just the icing on the cake and the things you would expect.
With this in mind, it's easy to see why you're wrong. At this point in time, there does not exist enough memory in the world to fill the 64 bit addressing space. So why on earth would anyone want a larger pointer, when we don't have anything to use it for?
While I'm sure this will change at one point (since 640 kbyte really isn't enough for everyone), it doesn't make sense to build a processor for requirements that might be 20 years away.
And in case you're wondering; the so-called 128 bit processors of today are really only 32 or 64 bit processors, but since we lack the terminology for describing a processor with 64 or 128 bit registors, memory bus width, internal processing capabilities etc., the marketing dudes get away with calling them 128 bit processors.
End of dry definition.
Bo Thorsen,
SuSE Labs.
You're wrong in this.
:-) But my point here is that there is no change in the way you think - no change in the coding philosophy.
I have been working for SuSE on porting gcc and binutils for x86-64 for over a year now, and it has been pretty painless. After we had the basic system running, I ported a fullblown but small linux system to it (sysvinit, linux-utils, vim etc.) and the only thing I had to do was to make configure scripts grok the x86_64-unknown-linux architecture.
If you take a look at the design papers on x86-64.org or amd.com, you will find that the architecture is very easy to port to. It's basically an athlon with 64 bit adressing modes on top (very simplified way of looking at it). What AMD has done is to do the exact same transition that Intel did from i286 to i386 - 16 to 32 bit.
The new architecture is impressively easy to handle, and gcc can by now optimize almost as good for x86-64 as for i386. It's really just a matter of recompiling.
And if you don't want to do that, run the 32 bit binary. The x86-64 architecture includes running i386 binaries at native speed. This is no marketing crap, it really is the same as you would expect from an athlon.
Of course, if your application has assembler in it, you have to port this. But take a look at the docs again, and you'll feel very much at home there. Actually the extra registers will give you a warm fuzzy feeling inside
I appreciate your point, because for a lot of platform it would be true. But on this one it simply isn't.
Bo Thorsen,
SuSE Labs.
If there's one thing I agree with Rik Van Riel about, it's that further kernel hacking won't help Linux be adobted further.
The real problems for Linux exist in the middle layers, all the things between the kernel and KDE/GNOME. In here there is vast amounts of work that needs to be done, and way too few people doing it.
I have difficulty understanding why it is that people focus so much on kernel development, when at this point in development gcc and glibc hacking is incredibly more important. This is the bottom of the system, controlling the performance of everything. And this layer is not good enough yet.
Now, if you really want to hack on the kernel, by all means do so. Don't let anyone tell you that it's not necessary or won't do any good. Because that's not what I'm saying here. But I am saying that you would do Linux a whole lot of good by choosing a different area than the kernel.
I know; it's difficult to choose another project when sites like Slashdot only gives any attention to Kernel hackers and KDE/GNOME releases. It's difficult to live in a meritocracy when people are not giving equal merits to the different parts of the system.
Last: Whatever you choose, stick with it. The one thing Linux really needs is a bunch of people who knows a *lot* about their topic. People like me who knows something of everything are not equally valuable.
Happy hacking,
Bo Thorsen,
SuSE Labs.
In various hacker circles we have often discussed the China market for one reason: Why don't we see more stuff coming out of China?
Red Flag Linux is one of the biggest (maybe biggest of us all) Linux distributors, but you still see nothing coming back to the society. Try to think of the last time you saw a patch from a chinese developer - it's very rare.
I would really like to see the chinese hackers contributing to the environment in the future. Then it would be really interesting how Linux is doing in China.
Bo Thorsen,
SuSE Labs.
I work on the Sledgehammer Linux port, so I regularly compile binutils, gcc, glibc, kernel, X and other stuff on my machines. Besides compiling, I use the machines to run the simulator for the chip. I'd say I stress my machines more than most people.
I have a Ghz Athlon workstation, a Dell 850 MHz Pentium 3 based Inspiron 8000 and a GHz Mobile Athlon based Compaq 1200Z.
My workstation is between two or three times faster than both laptops. Now, how can that be when they have somewhat comparable cpus? Because of a fact that a faster cpu or graphics card can't change: The I/O subsystem in a laptop is so horrible that it's beyond comparison with our workstation I/O. And, have in mind that the x86 PCs have the worst I/O performance of all architectures. Whenever I fire up the simulator, then the laptops are pretty fast, because that is almost exclusively cpu bound. Compiling or other more full-system stuff makes the laptops crawl.
I'd say to every gamer or hacker out there: Don't buy a laptop because you think it's a desktop replacement. The overall system performance on them sucks and you will be disappointed. By a laptop if you need a mobile computer.
Bo Thorsen,
SuSE Labs.
I have been working for SuSE Labs on the X86-64 port for about a year now, and I thought you might be interested in hearing about the state of the port.
Back in march we saw the first printf ("Hello World\n") succeed in the simulator. This is quite a big thing because it needs a working compiler, binutils, glibc and kernel. Since then we have steadily improved the system. By now we're running a full fledged Linux system in the simulator. The system is partly 64 bit and partly 32 bit. We will use the native 32 bit capabilities of the chip to use 32 bit binaries when that makes the most sense (who needs a 64 bit ls when a 32 bit ls does 64 bit filesystems fine).
By now gcc (C and C++ support), binutils, glibc, gdb, the kernel, ncurses, bash, util-linux, vim etc. have all been ported almost completely. And X runs happily in 64 bit too. Now we need the desktop systems, apache, databases etc.
Shameless plug: I'm giving a one-hour talk about Linux on X86-64 at Linux World Frankfurt next tuesday, october 30th. Here I'll show the system running, give an overview of what porting Linux is and describe the new features for Linux that we have implemented.
Bo Thorsen,
SuSE Labs.
Please don't take this as a bad sign. SuSE is just restructuring a bit and there is absolutely no signs of the company going under or whatever other gloomy future timothy has in mind for the company.
Merging with Mandrake is a ridiculous proposition and it's incredibly bad behaviour of a journalist (or someone acting in this role) to suggest something like this.
Bo Thorsen.
Disclaimer: I work for SuSE Labs, but I speak for myself.