Slashdot Mirror

Anyone not on the "SJW" bandwagon is "blackballed" and their free software projects taken down. ( early example: http://esr.ibiblio.org/?p=6537 ) gnu utilities (unix utilities even) are being binned and replaced with systemd, choice is gone.

It was good while it lasted.

----

OpenSource release story removed due to developers opposition to Social Justice.

A story on the Phoronix linux news site about a release of an Open Source videogame was manually removed after a few days.
The reason cited was the developer's views on social issues such as gender equality (1).

The release story was titled "Xonotic-Forked ChaosEsqueAnthology Sees New Release - Phoronix" and can be accessed via the google cache(2).

Are the social or political views of an author of free software relevant to that software's inherent quality?
Should the beliefs of an opensource developer weigh when when evaluating whether a piece of opensource software is worthy of any publicity or public notice?
Should men with unpopular or "forbidden" views be excised from the opensource movement and "not allowed" to contribute, in a manner similar to that which is done in employment?
Has the free/opensource software movement changed in these respects since its founding? If so is this a positive change?
Should there be gatekeepers to opensource that decide who may and who may not contribute. Should abusive developers be "blackballed" to maintain proper social order and controls?

Citations:
(1) http://www.phoronix.com/forums...
"Fortunately, the article has been removed now."
"Thanks everybody for speaking up."
(2) https://webcache.googleusercon...

Removed story URL:
http://www.phoronix.com/scan.p...

From: Bill Gates
Sent: Sunday, January 24, 1999 8:41 AM
To: Jeff Westorinen; Ben Fathi
Cc: Carl Stork (Exchange); Nathan Myhrvold; Eric Rudder
Subject: ACPI extensions

"One thing I find myself wondering about is whether we shouldn't try and make the "ACPI" extensions somehow Windows specific.

It seems unfortunate if we do this work and get our partners to do the work and the results is that Linux works great without having to do the work.

Maybe there is no way to avoid this problem but it does bother me.

Maybe we could define the APIs so that they work well with NT and not the others even if they are open.

Or maybe we could patent something related to this."
-------

A possible bug in Foxconn boards BIOS affects Linux ACPI

Foxconn Does Hate Linux Support

News agencies all around the world are reporting about the astonishing event of the default wallpaper of Ubuntu being purple in color. Will Cooke, the Ubuntu Desktop Engineering Manager at Canonical, today posted the official Ubuntu 15.04, codenamed the Vivid Vervet, wallpaper. Even more shockingly, he also posted the official alternate wallpaper. As Ubuntu is extremely buggy, the announcement of the new wallpapers was reported as a bug too.

GCC was never "the best compiler out there".

Yes it was and is.

At one point it was SO bad that they had to switch to EGCS and rename that to GCC.

One version of GCC was bad once does not imply

. You can also get compilers from Intel, Pathscale, etc., that perform better. Pick your poison :-)

Yeah and GCC is beater in a number of measurable areas.

GCC supports more processors.

In terms of language support, GCC has them all beat to hell.

In terms of C++11 and C++14 support, GCC got there far before all of them (excpt LLVM/C++14).

GCC still has the best optimizer of all the compilers except for Intel on Intel processors (not even x64 since Intel hobbles performance on non intel compilers). GCC beats Pathscale http://www.phoronix.com/scan.p...

Oh and actually with recent GCC, it often outperforms the intel compiler too:
http://news.dice.com/2013/11/0...

It also seems emperically to be the most robust compiler with fewer ICEs than any of the others. So to sum up, GCC has:

More instruction sets
More languages
Better C++ support (LLVM beat it to C++14, GCC caught up)
A better optimizer
More robust

Than basically every other compiler.

About the only thing GCC doesn't yet do as well is optimize for size rather than performance, where IAR embedded workbench seems to be the winner though holy fuck that's otherwise a heap of shit). There also seem to be some specialist FORTRAN compilers which do a bit better on some FORTRAN benchmarks.

But nonetheless, I am 100% confident in stating that GCC is the single best compiler out there and nothing beats it in more than isolated categories. Or if you prefer, if you had to pick one compiler to work with to the exclusion of all others you'd be mad to chose anything other than GCC.

The GCC/ECGS thing is ancient history and totally meaningless to the performance of the recent compiler versions.

Allwinner is suspected of being a GPL violator, meaning if you want to build a product you'll be stuck with binary blobs.

Do you have a link for that? It's not that I disbelieve you, I strongly suspect that Intel would do that crap. I'd like to read more about it however if you hae a link handy, then stash the link for the next time this benchmark comes up.

Personally, I like the Phoronix Linux benchmarks. They're more meaningful for me since I use Linux and they're all based on GCC which is trustworthy.

http://www.phoronix.com/scan.p...

The i7 4770 ocasionally blows away the FX8350 by a factor of 2, but in many benchmarks they're close, and Intel loses a fair fraction. The 4770 is the best overall performer, but not by all that much. It seems that the choice of CPU is fairly workload dependent.

For servers, I still prefer the supermicro 4s opteron boxes. 64 cores, 512G RAM, 1U. Nice.

The i7 4770k is a fairly high end chip by Intel. I own one but I would not expect to find one in a sub 700. It is not a Xeon, but it is just 1 notch down from the $900 extreme edition so it is 2nd highest in consumer non server chips.

Well sites like tomshardware.com make it look like a Pentium or i3 can smoke the latest AMD black edition fresh out of the water. However, biased or not my real world experience says otherwise as many games are optimized for intel and use NVidia specific directX extensions with their studio software which boils a lot of AMD users blood but it is the truth.

In SWTOR I got a doubling of FPS from moving from a PhenomII black edition to an i7 4770k. True it has less cores but apps are optimized still for single tasking and I do have 4 real and 4 hyperthreaded cores for my VMs.

Reason being are games are crappy xbox ports. The 360 I think was single or dual core so games were single threaded. Therefore they kick ass on Intel. The only good news is the xboxONE is changing this with 8 cores with an AMD and forcing game makers to optimize more for ATI.

I expect the newer games to be more competitive as a result as they are more threaded and ATI optimized on tomshardware.com and other sites.

But damage is done and the power is much better with intel chips as they leave AMD further and further in the dust with lower chip nm sized dies since AMD sold their foundries. Global Foundaries only cares about ARM chips so sorry AMD stay in 2010 ... Intel is going 10nm next year and will finally put the last nail in the coffin. ... I pray NOT!

Do you have a link for that? It's not that I disbelieve you, I strongly suspect that Intel would do that crap. I'd like to read more about it however if you hae a link handy, then stash the link for the next time this benchmark comes up.

Personally, I like the Phoronix Linux benchmarks. They're more meaningful for me since I use Linux and they're all based on GCC which is trustworthy.

http://www.phoronix.com/scan.p...

The i7 4770 ocasionally blows away the FX8350 by a factor of 2, but in many benchmarks they're close, and Intel loses a fair fraction. The 4770 is the best overall performer, but not by all that much. It seems that the choice of CPU is fairly workload dependent.

For servers, I still prefer the supermicro 4s opteron boxes. 64 cores, 512G RAM, 1U. Nice.

I'm running the Aurora build (v38) and no. That could be just debian testing, of course. :) But *I think* I have all the relevant codecs installed.

MSE & H.264 is in red on https://www.youtube.com/html5

I might wait for a kernel and xorg update - intel has native VP8 support for their Bay Trail Atom chips. http://www.phoronix.com/scan.p...

just 300k lines of code.

Actually, that is wrong. Systemd is well over 550k lines of code, and close to 1500 files.

There are operating systems with lower counts of lines of code. Even the entire Space Shuttle was run on less than that, and Minix is 3 orders of magnitude smaller for the entire operating system. Here is a nice graphic

The other init systems are much more modest. Even upstart is only around 40k lines of code. The source code of launchd for instance is very compact.

Furthermore, systemd is not only huge, it is entirely unportable. All the other init systems have been ported to other unix systems because they actually preserve POSIX. Even Apple, who has a tendancy to do proprietary things, has made their launchd portable to other systems. Systemd doesn't even care about POSIX compatibility in the slightest, and even detests this standard.

All those complaints about Windows being bloated are actually nothing compared to Red Hat Linux now, which has more code in its INIT system than the original WIndows 3.1 release.

In short it is a bloated project that will probably die under its own weight.

I have encountered all of that information too. However, the situation has been improving. I can't say how much of that improvement is due to AMD and how much is due to open source developers that are good at reverse engineering. http://www.phoronix.com/scan.p... Also, I had those Minecraft crashes on Ubuntu 14.04, 14.10, and 15.04 alpha - that article I linked has kernel 3.18 (same as Ubuntu 15.04 alpha), Mesa 10.5-devel (15.04 alpha has 10.4.something), and open source radeon driver 7.4.99 (15.04 has 7.4.0). Maybe if I compiled my own driver and mesa I would get better stability, but I can't be sure.

I'm an AMD fan from way back because of the monopoly tricks Intel pulled in the late 1990s early 2000s ( https://en.wikipedia.org/wiki/.... ) - I figure Intel has the money and resources to put towards open source today because of the advantage they unfairly gained due to tricks then.

It's funny because SystemD integration of VLC has actually begun.

Because the people behind gtk3 are actively hostile to everyone but the GNOME project. Not only breaking functionality that non-GNOME projects need, but seeking out GTK applications and pressuring them to remove functionality just because GNOME Shell no longer uses it.

Details and further criticisms are all over the web; a couple starting points are here or here .

GTK is generally seen as a dead end these days. Many if not most of the folks who develop GTK apps that aren't part of the core GNOME project are scrambling to port to QT or something else. And GNOME itself is a struggling project and has been bleeding market share for 4 years now.

Broadcom Open-Sources VideoCore IV 3D Graphics Stack
Eric Anholt Makes Progress With Broadcom VC4 Graphics Driver

Broadcom Open-Sources VideoCore IV 3D Graphics Stack
Eric Anholt Makes Progress With Broadcom VC4 Graphics Driver

I'm no serious parallel programmer, so I don't know how helpful this well be to you, but this might be of interest: 22-Way AMD/NVIDIA OpenCL Linux Benchmarks To Start Off 2015. Mike Larabel does some great work.

Righto. ZFS performs amazingly when not compared to anything. Look, even fanbois admit that ZFS is slow on "simple configurations", like for example... one disk. And it is a memory hog, do we agree? Here are some benchmarks. ZFS last by a mile. Look, we know the drill. ZFS fans talk a great filesystem. It only looks good when you don't compare it to anything. BTW, ZFS is a disgusting mess inside that nobody has the courage to touch in any substantive way now that Sun has paid the death penalty for being stupid. No wonder it has proved impossible to implement a repairing fsck.

Righto. ZFS performs amazingly when not compared to anything. Look, even fanbois admit that ZFS is slow on "simple configurations", like for example... one disk. And it is a memory hog, do we agree? Here are some benchmarks. ZFS last by a mile. Look, we know the drill. ZFS fans talk a great filesystem. It only looks good when you don't compare it to anything. BTW, ZFS is a disgusting mess inside that nobody has the courage to touch in any substantive way now that Sun has paid the death penalty for being stupid. No wonder it has proved impossible to implement a repairing fsck.

OSX is slow as balls compared to Linux, on Apple hardware no less.

benchmarks.

Postmark on Ubuntu on an Air is THREE TIMES as fast on Ubuntu as Linux. Probably because HFS is an abomination. Even graphics accelaration is much better with Linux. MAFFT is more than twice as fast.

try this. That's a lot of source to maintain (don't forget, you've got to include not just the binary kernel but also the loadable modules to get the run-time kernel effective size, otherwise you're hiding bloat).

It would seem your baseless assumptions are wrong.

Sure, that was 3 years ago. But you seem to be ignoring the following facts:

• AMD's proprietary driver shares most of its code between Windows and Linux.

True enough, AMD OpenGL is actually equally bad on both platforms. It just happens that OpenGL is largely unused on Windows, so driver quality on that platform is mostly judged by Direct3D performance and stability.

This article from only a week ago indicates that the Linux AMD drivers are still quite terrible. I think maybe this current article is an attempt at some damage control.

It would seem your baseless assumptions are wrong.

Sure, that was 3 years ago. But you seem to be ignoring the following facts:

• AMD's proprietary driver shares most of its code between Windows and Linux.
• NVIDIA's proprietary driver shares code between Windows, Linux, Solaris, OSX and assorted BSDs.
• The majority of a device driver has to do with the device itself, and all kernels are trying to get the device to do the same thing and so will expect similar hooks. It is annoying to support multiple targets, but certainly not difficult.

Has the lockup issue been solved?

http://www.phoronix.com/scan.p...

http://www.phoronix.com/scan.p...

One of the largest cross platform gaming engines today is based on Mono the open source implementation of .NET

http://docs.unity3d.com/Manual...

From mono also comes...

http://xamarin.com/

A very good cross platform development tool for developing mobile apps.

The CLI (http://en.wikipedia.org/wiki/Common_Language_Infrastructure) was always open. Microsoft has worked with Mono developers from the get go and has even funded them...

http://www.phoronix.com/scan.p...

The notion that this is a recent renaissance is a complete fallacy. Microsoft understands that like any other company that when people leverage your technologies there are many opportunities to make money.

Open Source is not inconsistent with their strategies, which are all about making money and dominating the market, like every other company on the planet.

just in case your are not sarcastic.. . http://www.phoronix.com/scan.p...

Another turn in the wrong direction, in my opinion, is Wayland, which breaks many highly useful (to users) capabilities provided by X11.

If Keith Packard thinks Wayland is a good idea, I'm inclined to trust him. And, he does.

Perhaps you don't fully understand what Wayland is or why the senior X11 developers think it is a good idea. Please read through this and see if it changes your mind:

http://www.phoronix.com/scan.php?page=article&item=x_wayland_situation&num=1

In fact, someone on the Phoronix forums posted a bunch of links to Joey's debian-devel posts which seems to bear this out.

Especially the first one is a clanger. If you can't support systemd on technical grounds without getting threats, something is very toxic indeed.

And no, that first post is not directly related to the Debian Constitution. That the idiotic GR trying to override the Technical Committee decision two weeks before the Jessie freeze is inspired by this kind of drivel, and that the Constitution makes these kind of purely political overrides of the technical decisions possible is rather evident though.

From what I read there, stuff like https://lists.debian.org/debia... (trying to make technical decisions via politics when there actually is no disagreement between devs which needs any help with the decision-making) also contributed to his decision to quit.

In fact, someone on the Phoronix forums posted a bunch of links to Joey's debian-devel posts which seems to bear this out.

Especially the first one is a clanger. If you can't support systemd on technical grounds without getting threats, something is very toxic indeed.

And no, that first post is not directly related to the Debian Constitution. That the idiotic GR trying to override the Technical Committee decision two weeks before the Jessie freeze is inspired by this kind of drivel, and that the Constitution makes these kind of purely political overrides of the technical decisions possible is rather evident though.

What about systemd trying to do too much? Ie, someone earlier said it was great that systemd did ntp and dhcp, which seems ridiculous to me; if those services had problems then get better services, don't just wrap them up into systemd. Were those written as examples of systemd services to be emulated, or do the systemd devs really think it's their job to subsume services?

Interesting problem; if systemd had taken existing sNTP and DHCP clients, modified them so they fitted the systemd user case, the systemd developers would have been accused of "subsuming" other projects.

I think it is important to understand why systemd made a sNTPv4 and a DHCP client; in both cases it was user requests, and it was all about OS containers. Most sNTP and DHCP clients are made for stand alone systems, but the OS container density on a system is between 10 to 100 times that of a system running VM's.

That means a server, instead of booting 5 VM's will perhaps boot 250 OS containers. That is 250 instances of Fedora/CentOS/Debian that all wants a DHCP lease and syncing time at the same time.
Reducing the time for getting a DHCP lease means significant time savings. In this case systemd developers improved DHCP connections times by reducing the time spent in getting a lease by a factor of 1000. Very cool.

As it is now, you can now boot an entire Linux OS container from zero in 100ms, including getting a DHCP lease. That again means Linux OS containers on demand.

http://www.phoronix.com/scan.p...
https://plus.google.com/+TomGu...

As you can see the DHCP client and server is implemented as a library, meaning everybody can use their work for their own super fast DHCP implementation.

Of course, no one is forced to use systemd's versions of sNTP or DHCP. Their versions are made for speed, not for features.

I like Mac hardware a lot less when they disable hardware when they detect a non Apple OS

@BeardedGNUFreak: "You would think even the 15 year old Slashdot kiddies that make up 'teh Linux community' would have had the foresight to never let another Miguel de Icaza type clown trash their precious little OS." post447641

Interesting quote, but I wonder what are the actual number of front-line developers that are involved in this 'movement' calling for a Debian fork. I would have thought it would be damaging mainly by producing incompatible versions and diluting the developer base.

Have you read this at phoronix? http://www.phoronix.com/scan.p...

would this help? its a 4 page article on it http://www.phoronix.com/scan.p...

have a read of these 4 pages, there are a few failings listed there. http://www.phoronix.com/scan.p...

this might be what he's talking about http://www.phoronix.com/scan.p...

Have you seen the videos about why X is fundamentally broken? Did you read the fine article? There are a lot of horrible flaws in X that cannot be fixed short of a rewrite.

I get the impression that you haven't done any research into this issue, and are dismissing it based on a stereotype. Familiarity breeds contempt, and I am sure that to some degree the trend you identify exists. However, devs don't usually go that far out of their way to make work for themselves just on a whim, and I do expect them to actually be able to identify flaws in their software. Also, you should not assume that just because something is 20 or 30 years old, that it does not have major flaws. Even ignoring Shellshock, there's a lot of justification for replacing X with something else. If you believe otherwise, maybe you can pop over to the Wayland dev channel and explain why they're all wrong and that they don't need to be spending time on it.

> http://www.phoronix.com/

Please don't link to Phoronix garbage -- all they care about is linking to themselves instead of actually linking to the source
i.e.

* https://lkml.org/lkml/2010/9/1... Linux 2.6.36-rc4
* https://lkml.org/lkml/2010/9/2... Linux 2.6.36-rc5 <-- alpha: fix a 14 years old bug in sigreturn tracing

Actually, I can't remember last Linux Zero-Day bug.

Linux has certainly had a number of security bugs that existed for many years and could have been exploited for privilege escalation and unauthorized access to machines:
5-year-old privilege escalation bug
8-year-old privilege escalation bug
14-year-old sigreturn bug

Now you could take the dismissive, naive approach and say these don't matter and weren't exploited simply because you didn't hear about it in any well-publicized, poorly-executed attack but how many more of these ancient (and recent) vulnerabilities exist in the Linux kernel unfixed and unbeknownst to the maintainers? There could be none (unlikely), there could be many (much more likely) and as the kernel gets more and more complex and more and more bloated with kernel-mode drivers in the source tree it becomes even more likely that security vulnerabilities will be incorporated and go unnoticed.

NB: I'm not discussing this in the context of Linux Vs something else or Open Vs Closed, just that the Linux kernel is no more secure than any other software.

Oh, I was thinking of putting the TPM on the GPU and treating the rest of the system as untrusted, rather than trying to control everything. Controlling everything would work as well; but steps on a lot more toes, makes a great many more things Your Problem, and lengthens the chain of critical-things-you'll-probably-screw-up-somewhere. The GPU vendor only has an economic incentive to control a few performance-related parameters tightly coupled to the GPU silicon, so as long as the card can know its own model number(presumably lasered into the die when parts were being binned) and verify the signature on a trivial little manifest file that provides performance settings for each model number, it need trust nobody else.

As it happens, Nvidia is apparently trying something along these lines. They are apparently verifying the whole firmware, and denying specific items to unverified firmware, rather than ignoring most of the firmware and only signing for the specific items; but the effect is fairly similar. GPUs are tightly coupled to their hosts; but they have enough onboard capability to implement what is effectively a 'locked bootloader' behavior without exerting control over the remainder of the system(any more than only applying updates from signed repositories requires control of the internet).

(What won't be pleasant, though, is Team Copyright demanding that all video memory where precious 'premium content' might momentarily reside be protected from access by everyone and everything.)

working open-source AMD Hawaii GPU support

I'm sure I'm not the only one thinking that's much more front-page-worthy than Xbox 'One' controller support.

Phoronix reports performance to be generally satisfactory (which, given the context, is pretty damn good).

And USB does need to be in the kernel for performance reasons when you're dealing with USB3 and devices like hard drives.

That is a common misconception, which has, in my opinion, lead to a lot of bad designs from the security perspective. Genode has USB3 support, and it does not do any drivers at all in the kernel (That is a USB driver from linux running outside of kernel space providing usb 3.0 support btw). They also support hard drives, and none of that support is in the kernel. There is a bit more discussion on the topic on their mailing list addressing performance of micro kernels in general which inherently have all such drivers outside of the kernel. You need a good design to make it work, but there is strong evidence it can be done (we have working examples). I recommend reading into the Genode project. Its really quite interesting (and impressive) from a security perspective, as well as a general system design one. They are tacking a nice purist approach to security focused on minimizing the trusted set.

Overall, 64 bit has a 20% [or better] performance increase for most workloads. There are other factors other than just size of pointers.

Size of pointers is not the major factor in cache flush since most of the cache is taken up by data items and not pointers. These data items are more or less invariant across compilation mode.

64 bit compilers only use 64 bit fetch for non-pointers if you actually request them (e.g. long long). MS is the odd ball and defines a "long" to be 32 bits even in 64 bit mode [contrary to the compilation models used by everyone else]. "int" suffices for most data. Where it doesn't, one will [have to] code "long long" and that is invariant across 32/64, except that the 32 bit code will be slower [generating 2-3 instructions for each 64 bit one].

With x86_64, the first 6 arguments to a function are passed in registers and not on the stack (i.e. no wasteful push/pops for argument passing on entry/exit).

For a function that has a lot of automatic [stack] variables, in 32 bit, any non-trivial loop could spend a lot of time dumping a register to its stack frame solely for the purpose of making room for another variable that needs the register. This is register pressure and is considerably higher in 32 bit mode.

Once an address has been loaded in a register, access relative to that base register is identical speedwise between 64 and 32 bit.

64 bit has RIP-relative addressing which allows data to be addressed as small offset from the RIP [instruction pointer/program counter] register. Since it's relative to the RIP, two consecutive instructions that address the same data location will have slightly different offsets within each instruction.

You want a study? Try a google search on "performance 32 bit vs 64 bit".

Or, the easy reader version:
http://www.phoronix.com/scan.p...

The Rockchip 3066 appears to use ARM's proprietary Mali T-series graphics. No, thanks.

Quote from the dev lead on the Mali graphics:

"I really do understand your frustration and I'm sorry that this makes life harder for you and similar developers. We are genuinely not against Open Source, as I hope I've tried to explain. I myself spent a long time working on the Linux kernel in the past and I wish I could give you a simple answer. Unfortunately, it is a genuinely complex problem, with a lot of trade-offs and judgements to be made as well as economic and legal issues. Ultimately I cannot easily reduce this to an answer here, and probably not to one that will satisfy you. Rest assured that you are not being ignored. However, as a relatively small company with a business model that is Partner driven, the resources that we have, need to be applied to projects in ways that meet Partner requirements."
—(2014-09) ARM Still Not Doing Open Drivers

Except it does: http://www.phoronix.com/scan.p...

True, but the number of places where it uses gcc extensions is actively being reduced.

http://www.phoronix.com/scan.p...

How can it be production-ready if it still lacks SELinux support.. the ZOL FAQ suggests either permissive or disabling of it entirely", Kahenraz

ref ref

No, my point is that there are quite a lot of articles re: GCC vs. Clang on Phoronix, and that the comparisons are quite a bit more thorough and the results more varied than the parent hinted at with his/her implied claim that ‘the’ Phoronix article proves how GCC runtime performance is better. I read another article (at http://www.phoronix.com/scan.p...), and though it’s half a year old, it still shows that the compilers can be neck to neck in one area, and that they beat one another in various tests. So neither can claim absolute superiority.

Ahh, and here comes the shill, with the usual personal attacks and strawmen. Yes, go ahead and praise Poettering's cult of personality and ignore the many people in this very thread who rebutted the nonsense that there was a need to replace "init scripts". By focusing on that point alone you get to pretend that systemd is "just an in init system", and hasn't embraced and extended a long list of other tools.

Evidence? LOL. More evidence that you are either lying to push propaganda, or shockingly ignorant of what Poettering himself has said about the state and future of systemd. Or do you not consider the creator and manager of systemd to be a reliable source? Do you want to still pretend this issue is about "just an init system"? Because that would essentially be calling Poettering a liar.

I'm sure you won't bother properly understanding this... at least in public. Obviously, the goal is to simply bully the people who disagree with you. Sorry, no, we aren't going to simply shut up, and stop pointing out how Linux worked just fine, despite your unsubstantiated assertions.

You want a suggestion on how to fix things? Stop breaking everybody else's code! Any minor problem that sysvinit had has been vastly overshadowed by the breakage systemd has caused.