Including Codd himself. Not all of them, but he's certainly put them up for revisiting. Specifically, he's not at all fond anymore of NULL (Rule #3 of the 12 rules). Anyone who believes their own principles are final and immutable is simply deluded.
Details of the original model might be up for discussion, but the general principles of the model are not outdated, and that was my point.
Codd actually provided two different "null" values which encode two different meanings: A-MARK (data not available) and I-MARK (data not applicable). With hindsight, any kind of null is probably evil. Of course, without nulls, your relations must be normalized.
SQL and Access are not the place to start. Relational database theory starts with exactly that -- theory.
The relational model, as invented by E. F. Codd, is heavily grounded in mathematics and set theory, and exists independently of higher-level access interfaces such as SQL.
You can certainly teach people to create and use databases through Access or SQL, in the same way you can (to pick a randomly politically incorrect analogy) teach people to create bombs without telling them how chemical reactions work, but then you're not telling them the full story.
Knowing what a Cartesian product is, or what normalization and the five normal forms are, or what relational integrity is -- all that lets you design better, more flexible and extensible schemas, and interact more intelligently with your data. I know Access developers who don't have a clue about the relational model, and as a result design terrible applications.
As an aside, what's surprising is how many people consider Codd's original ideas outdated. The fact is, his ideas surpass what's implemented in database systems at the moment. SQL is a weak language (and SQL99, with its silly object orientation extensions, hasn't made it any better). Database vendors routinely expose underlying implementation issues to the user. They tightly couple physical representation with logical representation, leading, for example, to many people avoiding normalization because it incurs a significant performance penalty with most databases. RDBMSs today are crap.
A lot of the points you make have been (somewhat) solved with the JDK 1.4.2.
No. "Look and feel" plugins to Swing aren't enough. They're just fake props.
What if you're running a special GTK or XP theme?
What when the OS' look is upgraded? Swing apps won't automatically adapt to a changing OS. Good applications live for a long time.
What about accessability (eg., screen readers)?
What about fonts? (I'm actually asking. Last I checked, Swing had its own font system that was not integrated with the parent OS'. For 1.4.2 I'm sure they're using the Windows system font, for example -- usually Tahoma -- or at least I hope they do.)
I have never met a Swing app that doesn't feel totally alien on my desktop.
What the original poster neglects to mention is SWT only works on a fairly limited number of platforms, whereas Swing works wherever you can get a modern Java VM running.
Yes, Swing runs wherever you want, but the problem is that (a) it looks like crap, and (b) it doesn't integrate fully with the parent operating/windowing system. The former is less important if you only care about functionality; the latter is extremely important, period.
Non-native-looking/-behaving apps alienate users. Swing apps aren't affected by native themes, for example. I remember back when Swing didn't support the mouse wheel on Windows. Swing apps don't use Windows' native file dialogs. Consider accessability; Windows, Mac and GTK2 all have extensive APIs and technologies for screen reading and so on. Does Swing support them?
SWT already runs on a wide variety of platforms, and it's "driver" is small enough that adding support for new platforms isn't that much work. And the benefits are enormous.
Hmm, so what if I want to use your program on sparc solaris? Or maybe x86 solaris? Or BSD of some kind? Or sparc/ppc/whatever linux?
Eclipse runs on Solaris/SPARC. It probably also runs on the other platforms you mention, but there are no official binaries, and it might need a few patches to run on, say, FreeBSD. However, this being open source and all, nothing is stopping anyone from implementing suppport for these platforms.
How exacly does it make it possible to use native widgets on every platform where java works?
It doesn't. SWT only runs on supported platforms. The supported GUIs are currently Win32, GTK+ 2, Motif and Carbon. The supported platforms are Windows 98/ME/2000/XP, Linux/x86, Solaris/SPARC, MacOSX/PPC, AIX/PPC and HP-UX/HP9000.
Does it provide everything in a huge bundle that has to be installed along with your java program?
SWT is a library that consists of Java code plus native bindings implemented using JNI. You obviously need the SWT JAR, and you need the binding for your platform, which is a single, quite small shared object file (the Win32 SWT DLL is ~270KB).
Eclipse doesn't need Sun. Eclipse has, all on their own, managed to create an incredible piece of engineering that brings Sun's technology work to shame.
As an Eclipse user and plug-in developer, I would rather see Eclipse evolve freely than see it encumbered by the huge porting effort required to merge it with Sun's technology.
The fact that SWT (Eclipse's GUI toolkit) and Swing (Sun's) are incompatible as far as philosophy and vision are concerned is also significant.
SWT lets Eclipse and users develop portable programs that look and behave exactly like native applications: on Windows my app will look like a Windows app, on Linux it will look like a GTK+ app, and so on. Swing, on the other hand, is a platform in itself; it does provide some hooks for native technologies (printing, mouse wheels, etc.), but it will never adapt to changes of the local platform. SWT apps, since they use native APIs, do; for example, on Windows 2000 Eclipse looks like a Win 2000 app; on XP it looks like an XP app, with no additional theming support needed in the toolkit.
Indentation/formatting (especially on pasting) seems to be horrible broken in M5, and "Organize Imports" suddenly stopped working for me. I'm switching back to M4. Just FYI.
To support a specific "native" windowing toolkit, you don't reimplement SWT. You just implement the lower layer, the driver. Motif, GTK+ and Win32 support are each implemented using JNI.
Are the M4-5 releases stable enough for general development use?
Definitely. Though I have not tried M5 yet, I have been running the entire Mx series, with very, very few problems, and the issues have always been minor.
M3 seems the least stable so far. It had an awful indentation bug affecting us weird people who put line breaks before and after braces. M4, curiously, has what I would consider a similar bug (when you wrap a long expression to the next line, you expect the subsequent line to be indented by one step, whereas the indentation seems random; but then a lot of Java code seems indented this way for some mysterious reason). With M3 I also encountered a strange problem where the IDE would not remove compilation errors from its list even when they were corrected, and I had to delete all the projects and re-add them to make the problem go away.
It can't be said enough- PostgreSQL is now MUCH faster...and due to features like stored procedures, triggers, and some of the best locking available [...]
PostgreSQL still does "select for update" when doing insertions involving foreign keys. And that's bad, very bad.
What does this mean? When you insert a row that references another row, in the same table or a different table, as a foreign key, PostgreSQL will lock the row being referenced from being modified. Due to how PostgreSQL's "for update" works, it will also lock the row from being referenced by other insertions.
Consider these tables:
create table companies (name text primary key); create table employees (name text primary key, employer text references companies (name));
Then consider that connection A does the following:
begin; insert into employees ('John Doe', 'ACME Inc.');
Then a parallel connection B does:
begin; insert into employees ('Jane Doe', 'ACME Inc.');
What happens? Transaction B will actually block (ie., wait) either until transaction A commits, or a certain time limit (defined as deadlock_timeout in the PostgreSQL configuration file) is exceeded.
This defeats long-running transactions, and risks lots of deadlocks in a high-traffic environments. One workaround is to increase the deadlock timeout. A more predictable workaround is to disable constraint checking until transaction commit by marking your foreign keys as deferrable in the schema, and issuing a set constraints all deferred statement inside each transaction; this means you will only get reference-integrity violation errors on commit instead of on updates, but for many applications that's probably acceptable compromise.
I use explicit cursor fetch statements myself, but how do you use binary cursors? When I tried that (from Java, with PostgreSQL 7.3 and the standard 7.3 driver in Debain), I got errors -- stream errors, if I remember correctly.
FileDisk is a virtual disk driver for Windows NT/2000/XP that uses one or more files to emulate physical disks. A console application is included that let you dynamically mount and unmount files. An example of use for this driver is if you have made plans spending the weekend writing an RAID driver for NT but find you are short of disks. FileDisk can also use CD-images.
The color palate is more subdued than that of Fellowship, but colors are accurate at all times.
We have the annoying typo where clueless people write palette (tablet used by painters for mixing holding and mixing colours) instead of pallet (portable platform for storing and moving goods), leading to interesting imagery. I didn't realize it went the other way, and these clueless people also misspelled palette as palate (the roof of the mouth, figuratively one's sense of taste). I wonder if the same people ever mispell palate as palette or palette as pallet. The mind boggles, constantly.
A year or so ago I clocked JFS, ext3, ReiserFS and XFS with a homemade script. JFS consistently beat out the others, so I settled on JFS.
These new benchmarks, while clearly not of the highest scientific calibre, only confirm something I have suspected for a long time: that JFS is among the fastest Linux file systems out there.
JFS is also the most underrated of the journaling file systems. I tend to cheer for the underdog myself. It's true that there were some serious bugs in earlier versions (I got bit by one myself), and this has clearly contributed to its completely undeserved image as a dusty old legacy abandonware file system. Clearly the lack of promotion on IBM's part is to blame; sometimes, hype is good.
Although both Random House Webster's Dictionary and the American Heritage Dictionary both list "Nordic" as being synonymous with "Scandinavian", on this side of the Atlantic the phrase "Nordic countries" ("norden" in most Scandinavian languages) specifically denotes the Western-Europe countries surrounding the Baltic Sea, which
the Nordic Council of Ministers
describes
as consisting "of five sovereign states and three autonomous territories: Denmark, Finland, Iceland, Norway and Sweden, along with the Faroe Islands, Greenland and Aland". Scandinavia, for the record, is Norway, Denmark and Sweden.
If you read the Council pages, you will notice that these states and territories communicate and co-operate, often in a cultural and economic context.
... an unbiased review of a the most important book ever to be written about... any subject for that matter.... If you don't know who Stan Lee is, you will have little to no interest in this book.
So it's the most important book ever written, but if I don't know who Stan Lee is, I won't care?
I was so ready to buy the hyperbole, and then you just shot me right down, didntcha.
I notice that the Xouvert project uses Arch revision control system -- indeed it relies on Arch's branching system to organize itself; as I understand it, the entire Xouvert project is one or more branches off one or more branches containing the official XFree86 sources. From the Xouvert site:
Arch is what makes Xouvert possible. Arch is Tom Lord's advanced changeset management system, a superset of mere "revision control systems" like CVS and Subversion. Arch will let us make radical changes to the directory layout of Xouvert, yet still be able to easily track and apply the changes in the original Xfree86 tree.
The clean design of arch makes it trivial for anyone who downloads our source code to create their own local "branch" for development, keep it under revision control, then have their modifications merged, with complete history, back upstream at some point in the future. This is next to impossible to do with CVS.
There are other projects that have started using Arch; for example, I noticed Y, mentioned in another comment, also uses it (just a coincidence, or a case of Y influencing Xouvert?).
Any slashdotters used it? I'm doing some testing with Arch and if I end up deciding I really like it, I'll try persuading my colleagues that we should adopt it as our company's source code management system. Mmm... atomic commits.
I admit I haven't tried Eclipse yet, but I would be very surprised if it were better than CodeWarrior.
You will be surprised.
Maybe not for C/C++ development: The Eclipse support (which is implemented, just the Java stuff, exclusively with plug-ins) currently consists of just the basics: syntax-aware editor, code outline, debugger, makefile support. There are no source code tools, no code completion, no cross-referencing tools (Doxygen/JavaDoc lookup, etc.).
The Java personality, however, is extremely complete and a wonder to use. It's in the little things, like the wonderful code completion, the cross-referencing with JavaDoc, the refactoring tools.
Eclipse is well-known for its neat source tools, some of them more intuitive than you would expect. Drag a class source file to another directory, for example, and it will not only update the file's package declaration, it will modify all dependent files' references to reflect the new location. Eclipse maintains an internal AST (abstract syntax tree) of the source code, so its source code manipulations are not based on text pattern matching, and the modifications it performs maintain formatting and consistency.
Among the more luxurious source-level tools are:
Rename -- renames any identifier and updates all uses of the identifier across all dependent projects.
Move -- moves a method into a different class, that class matching one of the arguments to the class. For example, in the class Foo, you can move the method execute(Bar b) into the class Bar; it will be implemented in Bar as execute(Foo f) (or without the Foo argument if not needed), and the original class will retain the method as a stub call to the new, moved method.
Push Down/Pull Up -- moving methods/fields up and down in the inheritance hierarchy, with all dependencies maintained.
Extract Interface -- takes one or more of a class' methods and puts them in an interface declaration.
Extract Method -- you select a bit of code, Eclipse wraps it in a method with all dependent variables and exceptions in the declaration, replaces the original code with a method call, and optionally searches for similar patterns elsewhere to replace as method calls. I use this one daily.
Among other favourites are Generate Delegate Methods (ideal for doing GoF "Decocator Pattern" classes), Generate Getter and Setter, Override/Implement Methods, Inline, and several tools to turn expressions into local vars, local vars into fields, and more.
The notion of code completion is extended to encompass code repair: Warning/error markers provide interactive "quick fix" popups suggesting ways to fix/improve your code. Misspelled type name? Eclipse will suggest a list of possible types. Typed an unknown class? Eclipse will suggest to add an import for it. Unused identifier? Eclipse will suggest to remove it safely.
These tools really help, and take the drudgery out of doing time-consuming changes such as renaming a class or method. It allows me to be more spontaneous about code changes -- if I move something I can always move it back, or somewhere else -- and concentrate less on syntax and more on code.
Does CodeWarrior offer any such time-saving tools? To my knowledge the only IDE that comes close to Eclipse is IntelliJ IDEA, a Swing-based IDE which provides many of the same source tools (like intelligent renaming, moving, "quick fix" markers), an even some new ones (Make Method Static, Replace Constructor with Factory Method and others). IDEA also has a few other goodies, like code folding. But it's not free software, and it does not offer Eclipse's terrific plug-in API. And it's Swing.
Slashdot Mirror
Details of the original model might be up for discussion, but the general principles of the model are not outdated, and that was my point.
Codd actually provided two different "null" values which encode two different meanings: A-MARK (data not available) and I-MARK (data not applicable). With hindsight, any kind of null is probably evil. Of course, without nulls, your relations must be normalized.
The relational model, as invented by E. F. Codd, is heavily grounded in mathematics and set theory, and exists independently of higher-level access interfaces such as SQL.
You can certainly teach people to create and use databases through Access or SQL, in the same way you can (to pick a randomly politically incorrect analogy) teach people to create bombs without telling them how chemical reactions work, but then you're not telling them the full story.
Knowing what a Cartesian product is, or what normalization and the five normal forms are, or what relational integrity is -- all that lets you design better, more flexible and extensible schemas, and interact more intelligently with your data. I know Access developers who don't have a clue about the relational model, and as a result design terrible applications.
As a starting point, I recommend the books by C. J. Date, in particular An Introduction to Database Systems, 7th Edition ; his book The Database Relational Model: A Retrospective Review and Analysis: A Historical Account and Assessment of E. F. Codd's Contribution to the Field of Database Technology also looks very interesting.
As an aside, what's surprising is how many people consider Codd's original ideas outdated. The fact is, his ideas surpass what's implemented in database systems at the moment. SQL is a weak language (and SQL99, with its silly object orientation extensions, hasn't made it any better). Database vendors routinely expose underlying implementation issues to the user. They tightly couple physical representation with logical representation, leading, for example, to many people avoiding normalization because it incurs a significant performance penalty with most databases. RDBMSs today are crap.
No. "Look and feel" plugins to Swing aren't enough. They're just fake props.
What if you're running a special GTK or XP theme?
What when the OS' look is upgraded? Swing apps won't automatically adapt to a changing OS. Good applications live for a long time.
What about accessability (eg., screen readers)?
What about fonts? (I'm actually asking. Last I checked, Swing had its own font system that was not integrated with the parent OS'. For 1.4.2 I'm sure they're using the Windows system font, for example -- usually Tahoma -- or at least I hope they do.)
I have never met a Swing app that doesn't feel totally alien on my desktop.
Yes, Swing runs wherever you want, but the problem is that (a) it looks like crap, and (b) it doesn't integrate fully with the parent operating/windowing system. The former is less important if you only care about functionality; the latter is extremely important, period.
Non-native-looking/-behaving apps alienate users. Swing apps aren't affected by native themes, for example. I remember back when Swing didn't support the mouse wheel on Windows. Swing apps don't use Windows' native file dialogs. Consider accessability; Windows, Mac and GTK2 all have extensive APIs and technologies for screen reading and so on. Does Swing support them?
SWT already runs on a wide variety of platforms, and it's "driver" is small enough that adding support for new platforms isn't that much work. And the benefits are enormous.
Eclipse runs on Solaris/SPARC. It probably also runs on the other platforms you mention, but there are no official binaries, and it might need a few patches to run on, say, FreeBSD. However, this being open source and all, nothing is stopping anyone from implementing suppport for these platforms.
How exacly does it make it possible to use native widgets on every platform where java works?
It doesn't. SWT only runs on supported platforms. The supported GUIs are currently Win32, GTK+ 2, Motif and Carbon. The supported platforms are Windows 98/ME/2000/XP, Linux/x86, Solaris/SPARC, MacOSX/PPC, AIX/PPC and HP-UX/HP9000.
Does it provide everything in a huge bundle that has to be installed along with your java program?
SWT is a library that consists of Java code plus native bindings implemented using JNI. You obviously need the SWT JAR, and you need the binding for your platform, which is a single, quite small shared object file (the Win32 SWT DLL is ~270KB).
As an Eclipse user and plug-in developer, I would rather see Eclipse evolve freely than see it encumbered by the huge porting effort required to merge it with Sun's technology.
The fact that SWT (Eclipse's GUI toolkit) and Swing (Sun's) are incompatible as far as philosophy and vision are concerned is also significant.
SWT lets Eclipse and users develop portable programs that look and behave exactly like native applications: on Windows my app will look like a Windows app, on Linux it will look like a GTK+ app, and so on. Swing, on the other hand, is a platform in itself; it does provide some hooks for native technologies (printing, mouse wheels, etc.), but it will never adapt to changes of the local platform. SWT apps, since they use native APIs, do; for example, on Windows 2000 Eclipse looks like a Win 2000 app; on XP it looks like an XP app, with no additional theming support needed in the toolkit.
Indentation/formatting (especially on pasting) seems to be horrible broken in M5, and "Organize Imports" suddenly stopped working for me. I'm switching back to M4. Just FYI.
To support a specific "native" windowing toolkit, you don't reimplement SWT. You just implement the lower layer, the driver. Motif, GTK+ and Win32 support are each implemented using JNI.
Thank you. That was useful information.
Definitely. Though I have not tried M5 yet, I have been running the entire Mx series, with very, very few problems, and the issues have always been minor.
M3 seems the least stable so far. It had an awful indentation bug affecting us weird people who put line breaks before and after braces. M4, curiously, has what I would consider a similar bug (when you wrap a long expression to the next line, you expect the subsequent line to be indented by one step, whereas the indentation seems random; but then a lot of Java code seems indented this way for some mysterious reason). With M3 I also encountered a strange problem where the IDE would not remove compilation errors from its list even when they were corrected, and I had to delete all the projects and re-add them to make the problem go away.
The call graph feature seems to be broken in M4.
- It can't be said enough- PostgreSQL is now MUCH faster...and due to features like stored procedures, triggers, and some of the best locking available [...]
PostgreSQL still does "select for update" when doing insertions involving foreign keys. And that's bad, very bad.What does this mean? When you insert a row that references another row, in the same table or a different table, as a foreign key, PostgreSQL will lock the row being referenced from being modified. Due to how PostgreSQL's "for update" works, it will also lock the row from being referenced by other insertions.
Consider these tables:
Then consider that connection A does the following:Then a parallel connection B does:What happens? Transaction B will actually block (ie., wait) either until transaction A commits, or a certain time limit (defined as deadlock_timeout in the PostgreSQL configuration file) is exceeded.This defeats long-running transactions, and risks lots of deadlocks in a high-traffic environments. One workaround is to increase the deadlock timeout. A more predictable workaround is to disable constraint checking until transaction commit by marking your foreign keys as deferrable in the schema, and issuing a set constraints all deferred statement inside each transaction; this means you will only get reference-integrity violation errors on commit instead of on updates, but for many applications that's probably acceptable compromise.
I use explicit cursor fetch statements myself, but how do you use binary cursors? When I tried that (from Java, with PostgreSQL 7.3 and the standard 7.3 driver in Debain), I got errors -- stream errors, if I remember correctly.
- The color palate is more subdued than that of Fellowship, but colors are accurate at all times.
We have the annoying typo where clueless people write palette (tablet used by painters for mixing holding and mixing colours) instead of pallet (portable platform for storing and moving goods), leading to interesting imagery. I didn't realize it went the other way, and these clueless people also misspelled palette as palate (the roof of the mouth, figuratively one's sense of taste). I wonder if the same people ever mispell palate as palette or palette as pallet. The mind boggles, constantly.Thanks a bunch!
Does anyone know who sings the song in the trailer?
How Far is It?
These new benchmarks, while clearly not of the highest scientific calibre, only confirm something I have suspected for a long time: that JFS is among the fastest Linux file systems out there.
JFS is also the most underrated of the journaling file systems. I tend to cheer for the underdog myself. It's true that there were some serious bugs in earlier versions (I got bit by one myself), and this has clearly contributed to its completely undeserved image as a dusty old legacy abandonware file system. Clearly the lack of promotion on IBM's part is to blame; sometimes, hype is good.
Go, JFS!
Why? That's what All Music Guide is for. AMG your friend.
If you read the Council pages, you will notice that these states and territories communicate and co-operate, often in a cultural and economic context.
So it's the most important book ever written, but if I don't know who Stan Lee is, I won't care?
I was so ready to buy the hyperbole, and then you just shot me right down, didntcha.
Remember, don't leave your CDs in the car for more than about a fortnight, or they will metamorphose into 'Best of Queen' albums.
The clean design of arch makes it trivial for anyone who downloads our source code to create their own local "branch" for development, keep it under revision control, then have their modifications merged, with complete history, back upstream at some point in the future. This is next to impossible to do with CVS.
There are other projects that have started using Arch; for example, I noticed Y, mentioned in another comment, also uses it (just a coincidence, or a case of Y influencing Xouvert?).
Any slashdotters used it? I'm doing some testing with Arch and if I end up deciding I really like it, I'll try persuading my colleagues that we should adopt it as our company's source code management system. Mmm... atomic commits.
You will be surprised.
Maybe not for C/C++ development: The Eclipse support (which is implemented, just the Java stuff, exclusively with plug-ins) currently consists of just the basics: syntax-aware editor, code outline, debugger, makefile support. There are no source code tools, no code completion, no cross-referencing tools (Doxygen/JavaDoc lookup, etc.).
The Java personality, however, is extremely complete and a wonder to use. It's in the little things, like the wonderful code completion, the cross-referencing with JavaDoc, the refactoring tools.
Eclipse is well-known for its neat source tools, some of them more intuitive than you would expect. Drag a class source file to another directory, for example, and it will not only update the file's package declaration, it will modify all dependent files' references to reflect the new location. Eclipse maintains an internal AST (abstract syntax tree) of the source code, so its source code manipulations are not based on text pattern matching, and the modifications it performs maintain formatting and consistency.
Among the more luxurious source-level tools are:
Rename -- renames any identifier and updates all uses of the identifier across all dependent projects.
Move -- moves a method into a different class, that class matching one of the arguments to the class. For example, in the class Foo, you can move the method execute(Bar b) into the class Bar; it will be implemented in Bar as execute(Foo f) (or without the Foo argument if not needed), and the original class will retain the method as a stub call to the new, moved method.
Push Down/Pull Up -- moving methods/fields up and down in the inheritance hierarchy, with all dependencies maintained.
Extract Interface -- takes one or more of a class' methods and puts them in an interface declaration.
Extract Method -- you select a bit of code, Eclipse wraps it in a method with all dependent variables and exceptions in the declaration, replaces the original code with a method call, and optionally searches for similar patterns elsewhere to replace as method calls. I use this one daily.
Among other favourites are Generate Delegate Methods (ideal for doing GoF "Decocator Pattern" classes), Generate Getter and Setter, Override/Implement Methods, Inline, and several tools to turn expressions into local vars, local vars into fields, and more.
The notion of code completion is extended to encompass code repair: Warning/error markers provide interactive "quick fix" popups suggesting ways to fix/improve your code. Misspelled type name? Eclipse will suggest a list of possible types. Typed an unknown class? Eclipse will suggest to add an import for it. Unused identifier? Eclipse will suggest to remove it safely.
These tools really help, and take the drudgery out of doing time-consuming changes such as renaming a class or method. It allows me to be more spontaneous about code changes -- if I move something I can always move it back, or somewhere else -- and concentrate less on syntax and more on code.
Does CodeWarrior offer any such time-saving tools? To my knowledge the only IDE that comes close to Eclipse is IntelliJ IDEA, a Swing-based IDE which provides many of the same source tools (like intelligent renaming, moving, "quick fix" markers), an even some new ones (Make Method Static, Replace Constructor with Factory Method and others). IDEA also has a few other goodies, like code folding. But it's not free software, and it does not offer Eclipse's terrific plug-in API. And it's Swing.
Hejlsberg.